| 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 | |
|
22:52
nine left,
nine joined
|
|||