|
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
|
|||