[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 [04:52] *** 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 [10:58] *** vrurg left [10:58] *** vrurg joined [11:21] *** leont joined [11:54] *** sena_kun joined [11:59] *** vrurg left [11:59] *** vrurg joined [12:04] *** vrurg left [12:21] *** Altai-man_ joined [12:24] *** sena_kun left [12:28] *** sivoais_ joined [12:29] 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 [12:31] 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 [12:32] 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] *** sivoais left [12:32] *** japhb left [12:32] *** gugod left [12:33] 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:34] *** vrurg joined [12:34] *** vrurg left [12:35] *** vrurg joined [12:37] *** japhb joined [12:40] *** gugod joined [12:57] 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 [13:35] *** vrurg left [13:36] *** vrurg joined [13:41] *** vrurg left [13:45] *** sena_kun joined [13:59] 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 [14:00] 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:01] 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 [14:02] but since we rely on it being nulled out in many places, could it possibly be cheaper to throw away and re-acquire? [14:07] also, i've seen sums of free-at-end-of-block sizes of around 300 kilobytes [14:14] *** vrurg joined [14:15] *** vrurg left [14:15] *** vrurg joined [14:17] 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:22] *** sena_kun left [14:23] *** sena_kun joined [14:23] *** Altai-man_ left [14:28] whoa, the biggest "wasters" have just above 2k blocks in them and waste a total of past 2 megabytes of memory [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 [16:17] *** 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 [19:37] *** linkable6 left [19:38] *** evalable6 joined [19:40] *** linkable6 joined [20:21] *** Altai-man_ joined [20:23] *** sena_kun left [20:52] *** patrickb left [20:52] *** vrurg left [21:17] *** zakharyas left [21:18] *** vrurg joined [22:22] *** sena_kun joined [22:24] *** Altai-man_ left [22:37] timotimo: In principle yes, though that uppercase mash of letters looks ugly compared to MVM_malloc ;) [22:40] i mean, naming is secondary :) [22:40] er [22:40] i'm not attached to the name, is what i mean [22:40] there's also the normal function variant, MVM_malloc_named, which i might have mentioned earlier [22:40] ah, i see where i mentioned it [22:40] in between the mountains of text :) [22:44] MVM_malloc_array or some such could work [22:51] *** Kaiepi left [23:45] *** leont left