github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 japhb left, japhb joined 00:27 japhb left, japhb joined 00:37 squashable6 left 00:39 squashable6 joined 00:53 frost-lab joined 01:15 lucasb left 01:55 frost-lab left 02:03 sortiz left 03:49 squashable6 left 03:52 squashable6 joined 05:17 notable6 left, statisfiable6 left, bloatable6 left, squashable6 left, quotable6 left, bisectable6 left, linkable6 left, tellable6 left, sourceable6 left, evalable6 left, committable6 left, benchable6 left, unicodable6 left, nativecallable6 left, coverable6 left, releasable6 left, shareable6 left, greppable6 left 05:18 evalable6 joined, quotable6 joined, committable6 joined, linkable6 joined 05:19 notable6 joined, bloatable6 joined, releasable6 joined, bisectable6 joined 05:20 statisfiable6 joined, shareable6 joined, coverable6 joined, sourceable6 joined, tellable6 joined, nativecallable6 joined, squashable6 joined, benchable6 joined, unicodable6 joined, greppable6 joined 05:58 frost-lab joined 06:15 frost-lab left 06:41 frost-lab joined 07:15 frost-lab left 08:13 frost-lab joined
nwc10 jnthn: it seems the most obvious explanation - "I'm sure that there used to be more liquid in this bottle" 08:15
well, better phrased as "I'm sure that the level of the liquid in this bottle has gone down all by itself since I last looked" 09:09
09:10 frost-lab left
nwc10 Always goes down for me. Apparently it can go up: www.youtube.com/watch?v=Qc65xFWhTIY 09:14
MasterDuke i'm stumped (and sure it's something blindingly obvious i'm just overlooking). valgrind points to github.com/MoarVM/MoarVM/pull/1426...3230cbR348 as being indirectly lost, but i'm freeing it here 09:33
github.com/MoarVM/MoarVM/pull/1426...510R48-R49 09:34
nine_ Could it be an omission in full-cleanup? When is that free_at_safepoint handled anyway? 09:39
MasterDuke i don't think so, since the direct loss is here gist.github.com/MasterDuke17/42853...d-log-L153 09:43
and gist.github.com/MasterDuke17/42853...-L119-L129 i guess 09:44
ha, does it even for -e '' 09:47
nine_ MasterDuke: I'd still try adding a MVM_gc_enter_from_allocator(instance->main_thread); or two before the call to MVM_gc_global_destruction 09:49
Just to be sure
MasterDuke nope 09:55
there is already one, i added two more github.com/MoarVM/MoarVM/blob/mast...#L645-L651 09:56
nine_ I notice that MVM_fixed_size_destroy does not do anything about the free list. Maybe try a MVM_fixed_size_safepoint at the start of MVM_fixed_size_destroy? 10:34
10:35 nine_ is now known as nine 11:27 domidumont joined
nine f/win 10 11:43
MasterDuke oh! adding `MVM_fixed_size_safepoint(instance->main_thread, instance->fsa);` right before `MVM_fixed_size_destroy(instance->fsa);` has fixed the leak 11:55
12:00 leont joined
MasterDuke even with the larger/longer example 12:03
how has this not come up before?
but, now that the leak finding yak shave has concluded, now to try to figure out/fix the extra memory churn... 12:23
all from MVM_fixed_size_alloc_zeroed in allocate_frame, so must be either/both github.com/MasterDuke17/MoarVM/blo...ame.c#L303 and github.com/MasterDuke17/MoarVM/blo...ame.c#L315 12:39
nine My guess is that the usual stuff we use the fixed size allocator for is small enough to fall into the bins that MVM_fixed_size_destroy takes care of. And all the large stuff get freed earlier than those spesh cands 12:52
15:12 patrickb joined
nine jnthn: I'm more and more sure that in the mis-spesh of is_type (leading to a NULL result of a decont) we already screw up during ssa creation. I'm stepping through rename_locals and it already believes that there's just one assigning node which is the one covered by the handler. It's ignoring the block before the handler area that initializes that register. 15:28
patrickb good *, o/ 15:41
nwc10: Did you notice my ping in github.com/MoarVM/MoarVM/pull/1385...-782059178 ? 15:43
nine I wonder why we don't treat throwish instructions more like branches in spesh. If an instruction can throw and we have a handler, why is the handler's block not a successor of the throwish op's block? And why does BB 1 not dominate the handler even though we must pass through it to even get to a throwish op? 16:03
17:39 sena_kun left 17:40 sena_kun joined
cog_ notes that MVM_spesh_plan_gc_describe is defined but not called anywhere in MoarVM. Do I miss something ? 17:43
part of other *gc_describe* , probably an unfinished attempt to do stats on Spesh related things 17:46
17:57 Altai-man_ joined, sena_kun left 18:25 domidumont left 19:21 zakharyas joined 19:34 MasterDuke left 19:37 MasterDuke joined 19:47 MasterDuke left 19:50 MasterDuke joined 21:06 patrickb left 22:15 zakharyas left 22:55 dogbert17 joined 22:56 dogbert11 left 23:30 Altai-man_ left 23:33 sena_kun joined