| 23 Sep 2026 | |||
| disbot | <_.mu._> My codebase is somewhat … pathological. There are 2 or 3 observations, and I shouldn't have started with nondeterminism. More important is this: | 20:18 | |
| <_.mu._> Memory footprint and time measured processing a 29k token input for different values for MVM_SPESH_LIMIT: | |||
| <_.mu._> LIMIT peak RSS wall 100 0.6 GB 20s 500 0.6 GB 20s 1000 0.6 GB 20s 2000 3.7 GB 61s | |||
| 5000 4.7 GB 84s unlimited 4.75 GB 84s | |||
| <_.mu._> So memory blows up at a certain point, and my question is if this solely is a property of my codebase or if there also is a MoarVM issue. My interpretation is that the number of possible specializations is exhausted somewhere below 5000. | 20:19 | ||
| <_.mu._> So to rephrase my question: Is it expected that you have to find the sweet spot yourself (1000 in my case), and that specializations accumulate memory with no eviction and no admission-cost/benefit control, so the VM can install dead weight that costs memory and time while earning nothing? | |||
| 24 Sep 2026 | |||
| timo | you can find out what spesh decides to do by having MVM_SPESH_LOG output to a file, but be aware that it is very verbose and can grow quite a lot if spesh builds lots of specializations | 10:42 | |
| there's different ways that spesh can allocate stuff. one is of course the specializations themselves (either bytecode, or if the jit is on and doesn't get bailed for some reason it will be machine code instead) | 10:53 | ||
| another is stats, which old stuff that hasn't been updated in a while gets cleared out from over time | |||
| there's also the in-line cache entries that live in slots for a given bytecode frame (MVMStaticFrame) and MVMStaticFrame don't generally get more over time unless your program compiles stuff at run time or loads more and more and more compilation units | 10:55 | ||
| inline caches for dispatching can have multiple entries if the dispatch turns out to be megamorphic, in which case when there's no match from the limited number of stored things it will run the dispatcher's code to figure out the correct thing to do and not store it | 10:56 | ||
| spesh itself will allocate memory to do its work and then when it's finished deallocates it all again, which can show as a big impact in maxrss but only actually be meaningful for short bursts in between | 10:58 | ||
| some frames can be quite large, which can give a lot of allocations, especially since the code in spesh doesn't re-use memory when changing stuff, it's sort of "copy on write", relying on the "free everything" step at the end to do everything | 10:59 | ||
| try running your workload under `heaptrack`, that should tell you a bit more about where allocations are going, though in order for that to work you may have to build a moarvm (and then also nqp and rakudo) with --no-mimalloc | 11:09 | ||
| then also use MVM_JIT_DISABLE=1 so you don't lose attribution to functions the jit compiled, I'm not sure heaptrack has a way to tell it what these functions are so they would probably 1) just show up as addresses and 2) it probably doesn't know how to unwind the stack after these, so the stack traces would either be completely messed up, or the functions would be in the wrong place in the stack | 11:10 | ||
| view | |||
| ShimmerFairy | I've been plucking away at various small issues around ucd2c.pl, but now I'm looking at adding proper support for complex default values (needed to fix the Line_Break property at least), and it's hard to ignore the desire to rewrite the whole thing in Raku. This overgrown script is hard to wrap my head around at times, and I also don't want to make it even worse for the next person. | 12:46 | |
| lizmat | +1 for rewriting in Raku | 12:50 | |
| disbot | <_.mu._> timo, thanks for explaining | 18:15 | |
| 27 Sep 2026 | |||
| Geth | MoarVM/2026.09: d0c4d3f652 | (Will Coleda)++ | 2 files Update changelog and version |
20:14 | |
| MoarVM: coke++ created pull request #2048: Update changelog and version |
20:15 | ||
| MoarVM/main: d0c4d3f652 | (Will Coleda)++ | 2 files Update changelog and version |
20:20 | ||
| MoarVM/main: 81362a223d | (Will Coleda)++ (committed using GitHub Web editor) | 2 files Merge pull request #2048 from MoarVM/2026.09 Update changelog and version |
|||
| 28 Sep 2026 | |||
| MoarVM/main: 6e5144cb6c | (Will Coleda)++ | 2 files || build for release (much faster) |
14:52 | ||
| ab5tract | ShimmerFairy: have you seen github.com/Raku/problem-solving/issues/437 ? | 15:30 | |
| 29 Sep 2026 | |||
| ShimmerFairy | I haven't seen that particular issue, but I myself have been annoyed with .uniprop's jankiness over the years. My hope is that replacing ucd2c.pl will make supporting unicode properties easier to do, though it's far from the only change needed. | 02:36 | |
| lizmat | And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2026/09/29/2026-...nstreamed/ | 13:22 | |
| 30 Sep 2026 | |||
| Geth | MoarVM: kliklamala++ created pull request #2049: debugserver: fix Invoke (36) deadlock on not yet instrumented code |
16:14 | |
| 3 Oct 2026 | |||
| MoarVM/unicode-18.0: 15 commits pushed by Faye++ review: github.com/MoarVM/MoarVM/compare/1...06d11226b1 |
12:02 | ||
| MoarVM: ShimmerFairy++ created pull request #2050: Update for Unicode 18.0 |
12:08 | ||
| ShimmerFairy | As mentioned in the pull request, I also picked off a couple of longstanding issues around properties in particular, though there's still work to be done in the future. | 12:10 | |
| lizmat | Let's see what CI says :) ShimmerFairy++ | ||
| if merged, would you like to see it squashed, or each commit merged separately? | 12:11 | ||
| ShimmerFairy | I don't mind either way. I was worried I make too many "atomic" commits, but I like keeping each thing I do separate. I think for the most part squashing it might make more sense as a single logical "update Unicode" commit (and likely helps the automated changelog checker I think we have), though it isn't strictly speaking *just* fallout from upgrading. | 12:14 | |
| The one big thing where squashing would help is with the big pregenerated source files, I had to generate them a couple times and eliminating a couple big files via squashing would possibly be a kind thing to do (depends on how specifically squashing works). | 12:15 | ||
| lizmat | my understanding is that it takes the diff of all the commits, and creates a single commit for that | 12:20 | |
| ShimmerFairy | That's what I figured. Like I said, it's fine either way with me. I think the only real loss would be the wordy explanations I wrote in my commits, but I think most of the "along the way" fixes are pretty obvious just by looking at them. | 12:23 | |
| Just in case there are CI breakages, I can at least attest to the NQP tests, rakudo tests, and spec stresstest (less Perl5 tests) working just fine, aside from one flappy repl test in rakudo and a spectest that always coredumps on me. | 12:27 | ||
| Ah, seeing the rakudo test failure, I suppose I should've seen the addition of two new huge blocks of characters causing problems with old tests coming. | 12:32 | ||