[03:11] *** Techcable left [03:12] *** Techcable joined [03:28] *** vrurg_ left [03:30] *** vrurg joined [04:47] *** ShimmerFairy left [05:05] *** sugarbeet left [05:05] *** sugarbeet joined [05:08] *** camelia left [06:22] *** disbot2 is now known as disbot [10:22] *** unicodable6 left [10:24] I've thought about having a little bit of storage after an object in the nursery a few times in the past; that would allow us to create new hashes with a minimum sized hash table immediately after it in the nursery and when it makes it out of the nursery we move that hash table to mi_malloc'ed storage. if the table doesn't make it out of the nursery, no malloc + free cycle is needed for it. this [10:24] requires a bit of a change to how we allocate things though because when allocating we just pass the STable and the size to use is taken from there. that's how MVM_gc_allocate_object does it [10:24] *** greppable6 left [10:25] *** bloatable6 left [10:25] *** bloatable6 joined [10:25] *** bloatable6__ joined [10:26] we don't have the problem described in that post where function calls use hashes, because our named arguments work by putting argument names in callsites; it's different when you flatten named arguments, but that's usually because you don't know the keys ahead of time [10:27] *** tellable6 left [10:27] *** tellable6 joined [10:27] I think the default value for a hash, as well as what comparison to use (object hashes vs string-keyed hashes) lives in the HOW in our case, so doesn't use up a pointer in the object itself [10:28] *** notable6 left [10:28] *** notable6 joined [10:29] I thought object hashes were identical to normal hashes at the VM level? [10:30] *** bloatable6 left [10:30] It's just that they carry Pairs as values (rather than just the value) [10:30] I don't think they have different HOWs? [10:30] *** bisectable6 left [10:31] I stand corrected [10:31] m: dd (my %h).HOW [10:31] lizmat, rakudo-moar a0a60ed3c: OUTPUT: «Cannot test a0a60ed3ce28e6e014bf287101a6d454e364aeaa (Commit exists, but an executable could not be built for it)» [10:31] (2026-08-21) https://github.com/rakudo/rakudo/commit/a0a60ed3ce Merge pull request #6577 from rakudo/release-2026.08 [10:31] *** quotable6 left [10:32] meh [10:32] it's probably the reason we lost camelia as well :-( [10:33] *** sourceable6 left [10:35] *** releasable6 left [10:36] they have the same HOW type, but different HOW instances, because they are different types. other than that yes, they are the same on the VM level in moarvm, but not in ruby [10:36] *** linkable6 left [10:36] *** linkable6 joined [10:37] or I guess the difference is in the WHAT, not the HOW [10:56] interesting: we don't inline `!cursor_fail` into the `-e:1 (cuid: 3)` from MasterDuke's example code (the one with the `\s+(\d+)` regex) because it uses `return_i`. I think that shouldn't actually be a problem for inlining, but we may have to handle it specifically? [11:07] adding a double-devirtualization for VMArray for push_i and pop_i could help remove a little bit of overhead from jitted regex code [11:08] maybe there's even some value in making multi-pop and multi-push instructions (or syscalls) as long as the JIT can handle them properly as well [11:08] I think we don't have any ops yet that write to more than one register, so spesh may need changes in many places to not trip over that [12:17] *** rakkable left [12:17] *** rakkable joined [12:56] <[Coke]> c: a0a60ed3c 3.say [12:56] [Coke], ¦a0a60ed: «Cannot test this commit (Commit exists, but an executable could not be built for it)» [12:58] <[Coke]> c: a5c48846b310c4e79e785b473f32dc928776d47f e.say [12:58] [Coke], ¦a5c4884: «2.718281828459045␤» [12:58] <[Coke]> opened a ticket for that a0a6 bad build [13:16] *** timo left [13:16] *** timo joined [14:05] *** linkable6 left [14:05] *** benchable6 left [14:05] *** shareable6 left [14:05] *** evalable6 left [14:05] *** bloatable6__ left [14:05] *** committable6 left [14:08] *** notable6 left [14:08] *** tellable6 left [14:08] *** huggable6 left [14:08] *** nativecallable6 left [14:09] *** benchable6 joined [14:09] *** benchable6__ joined [14:11] *** quotable6 joined [14:11] *** sourceable6 joined [14:11] *** nativecallable6 joined [14:12] *** linkable6 joined [14:12] *** greppable6 joined [14:12] *** unicodable6 joined [14:12] *** greppable6__ joined [14:14] *** benchable6 left [14:16] *** greppable6 left [14:21] *** nine left [14:21] *** nine joined [14:53] *** ShimmerFairy joined [14:53] *** nativecallable6 left [14:53] *** quotable6 left [14:53] *** unicodable6 left [14:53] *** sourceable6 left [14:53] *** linkable6 left [14:53] *** benchable6__ left [14:53] *** greppable6__ left [14:56] *** greppable6 joined [14:56] *** coverable6 joined [14:56] *** greppable6__ joined [14:56] *** tellable6 joined [14:56] *** shareable6 joined [14:56] *** sourceable6 joined [14:56] *** unicodable6 joined [14:56] *** bisectable6 joined [14:57] *** benchable6 joined [14:57] *** committable6 joined [14:57] *** quotable6 joined [14:57] *** releasable6 joined [14:58] *** evalable6 joined [14:58] *** bloatable6 joined [14:58] *** linkable6 joined [14:58] *** nativecallable6 joined [14:58] *** notable6 joined [14:58] *** huggable6 joined [15:00] *** greppable6 left [18:20] https://github.com/microsoft/mimalloc/issues/1373 stumbled over some fascinating behaviour of mimalloc in combination with Transparent Huge Pages [20:13] TL;DR of the resolution: having no memory "free" (as in: completely unused) means the kernel has to actively move pages with content around if it wants to compact pages together into a huge page transparently, and apparently that blocks the process that does the memory access that leads to that work? [20:14] freeing up some memory on the rest of the system leads to a performance benefit from allowing mimalloc to use THP [20:14] (that's what I've configured my system to do: when a process uses madvise with the "allow THP" flag, it will try to coalesce pages into huge pages) [21:42] ¦ MoarVM: MasterDuke17++ created pull request #2035: Bump mimalloc to v3.5.0 [21:42] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/2035 [21:47] <[Coke]> annoying that the one off "test on dragonfly" completes so much faster than the "standard" builds in CI [21:48] ¦ MoarVM/main: 2c16915d50 | (Greg Donald)++ | 5 files [21:48] ¦ MoarVM/main: Add code coverage instrumentation filtering [21:48] ¦ MoarVM/main: review: https://github.com/MoarVM/MoarVM/commit/2c16915d50 [21:48] ¦ MoarVM/main: fe50e5c704 | (Greg Donald)++ | src/moar.c [21:48] ¦ MoarVM/main: Drop env variable copying code. [21:48] ¦ MoarVM/main: [21:48] ¦ MoarVM/main: Free instance->coverage_file_filters. [21:48] ¦ MoarVM/main: review: https://github.com/MoarVM/MoarVM/commit/fe50e5c704 [21:48] ¦ MoarVM/main: cf7bdf25b1 | MasterDuke17++ (committed using GitHub Web editor) | 5 files [21:48] ¦ MoarVM/main: Merge pull request #2018 from gdonald/coverage-file-filter [21:48] ¦ MoarVM/main: [21:48] ¦ MoarVM/main: Add code coverage instrumentation filtering [21:48] ¦ MoarVM/main: review: https://github.com/MoarVM/MoarVM/commit/cf7bdf25b1 [21:49] <[Coke]> Can we get Changelog entries for those, thanks. [23:07] the "test on dragonfly bsd" seems to only be compilation? [23:07] oh, there it is, it does run the nqp test suite [23:08] I don't love that a good 2/3rd of the output is perl warning about not being able to set the desired locale ... [23:32] *** japhb left [23:32] *** japhb joined [23:43] <[Coke]> There was a PR for that and that note was made - if you really don't like it, he can fix it [23:44] <[Coke]> https://github.com/MoarVM/MoarVM/pull/2027 [23:44] it's not that bad, I don't have to look at it, and I don't think it influences the results any. it does make it pretty unlikely that anybody spots any interesting warnings in between though I guess? [23:44] <[Coke]> (or you can based on the notes there) [23:45] <[Coke]> yup, cleaner is probably better, you're right [23:46] *** camelia joined