github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:22 sena_kun joined 00:23 Altai-man_ left 01:22 vrurg joined 01:31 lucasb left 02:21 Altai-man_ joined 02:23 sena_kun left 04:15 vrurg left 04:16 vrurg joined 04:21 vrurg left 04:22 sena_kun joined 04:23 Altai-man_ left 04:51 vrurg joined 04:52 vrurg left, vrurg joined 05:17 vrurg_ joined 05:19 vrurg left 06:21 Altai-man_ joined 06:23 sena_kun left 07:23 vrurg_ left 07:24 vrurg joined 07:28 vrurg left 08:01 vrurg joined 08:05 vrurg left 08:10 vrurg joined 08:22 sena_kun joined 08:24 Altai-man_ left 09:10 vrurg left 09:11 vrurg joined 09:15 vrurg left 09:23 vrurg joined 09:27 vrurg left 09:53 sena_kun left 09:56 vrurg joined 10:57 vrurg left 10:58 vrurg joined, vrurg left, vrurg joined 11:21 leont joined 11:54 sena_kun joined 11:59 vrurg left, vrurg joined 12:04 vrurg left 12:21 Altai-man_ joined 12:24 sena_kun left 12:28 sivoais_ joined
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
12:32 sivoais left, japhb left, gugod left
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
12:34 vrurg joined, vrurg left 12:35 vrurg joined 12:37 japhb joined 12:40 gugod joined
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
13:35 vrurg left 13:36 vrurg joined 13:41 vrurg left 13:45 sena_kun joined
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
14:14 vrurg joined 14:15 vrurg left, vrurg joined
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
14:22 sena_kun left 14:23 sena_kun joined, Altai-man_ left
timotimo whoa, the biggest "wasters" have just above 2k blocks in them and waste a total of past 2 megabytes of memory 14:28
14:38 sena_kun1 joined 15:32 sena_kun1 left 15:43 vrurg left 15:44 vrurg joined 15:49 vrurg left 16:17 vrurg joined, vrurg left 16:18 vrurg joined 16:21 Altai-man_ joined 16:24 sena_kun left 17:14 zakharyas joined 17:24 vrurg left 17:25 vrurg joined 17:27 patrickb joined 17:30 vrurg left 18:06 vrurg joined 18:11 vrurg left 18:21 sena_kun joined 18:23 Altai-man_ left 18:28 vrurg joined 19:37 evalable6 left, linkable6 left 19:38 evalable6 joined 19:40 linkable6 joined 20:21 Altai-man_ joined 20:23 sena_kun left 20:52 patrickb left, vrurg left 21:17 zakharyas left 21:18 vrurg joined 22:22 sena_kun joined 22:24 Altai-man_ left
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
22:51 Kaiepi left 23:45 leont left

Powered by Cro and the Raku® Programming Language.

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

Thank you!