github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo jnthn: how do you feel about turning (TheType *)malloc(count * sizeof(TheType)) into MVMALLOCOBJ(count, TheType) all over the codebase? 12:29
because i still have that script that does it
it removes the duplication of spelling the type multiple times, takes care that there's one star more on the cast side, and instrumentation can access the type as a const char *, if it's active. otherwise i believe (and i should obviously check this) that it has no overhead 12:31
and the same for the fsa allocation functions and perhaps also spesh
other fun things that can be done: annotate every allocated pointer with the "type" in a shadow region or hash map or whatever 12:32
timotimo of course summing up memory allocations by "type" is also easily possible, though deallocations aren't as easy to map without keeping the type around based on the address 12:33
timotimo MVMALLOCOBJ is just one macro that uses MVM_malloc_named, that function takes any const char *, so we can also give names to other things 12:57
timotimo i've probed MVMRegionAlloc's region_alloc (via the regular callocobj probe when it creates a new region) and the destroy_region function and am grabbing both the number of blocks the region has and the amount of free space at the end of the last block 13:59
turns out we're destroying lots of region allocators when they have just the one block and like 20 to 25 kilobytes of remaining space 14:00
if we hold on to a single block for re-use, we may be able to avoid a lot of churn here 14:01
at first i thought to maybe re-use the region alloc in between candidates when we do a bunch in a row, which we usually do
but since we rely on it being nulled out in many places, could it possibly be cheaper to throw away and re-acquire? 14:02
also, i've seen sums of free-at-end-of-block sizes of around 300 kilobytes 14:07
timotimo there's even cases where we allocate something that's bigger than the default buffer size; sometimes there's a good amount of free space left in the block, though, but this will throw the previous block out as "nothing free any more!" and create a fresh new one of the "right" size, and i guess it'd immediately need a new extra region for whatever allocation comes next? 14:17
timotimo whoa, the biggest "wasters" have just above 2k blocks in them and waste a total of past 2 megabytes of memory 14:28
jnthn timotimo: In principle yes, though that uppercase mash of letters looks ugly compared to MVM_malloc ;) 22:37
timotimo i mean, naming is secondary :) 22:40
er
i'm not attached to the name, is what i mean
there's also the normal function variant, MVM_malloc_named, which i might have mentioned earlier
ah, i see where i mentioned it
in between the mountains of text :)
jnthn MVM_malloc_array or some such could work 22:44

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!