[00:33] *** mst left
[00:33] *** mst joined
[00:33] *** ChanServ sets mode: +o mst

[03:55] *** avar joined
[03:55] *** avar left
[03:55] *** avar joined
[06:48] *** rypervenche left
[06:48] *** moon-child left
[06:48] *** hoelzro left
[06:48] *** Altreus left
[07:25] *** moon-child joined
[07:25] *** rypervenche joined
[07:25] *** hoelzro joined
[07:25] *** Altreus joined
[07:30] *** sena_kun joined
[08:21] *** domidumont joined
[09:29] *** leont joined
[09:39] *** avar left
[09:46] *** avar joined
[09:46] *** avar left
[09:46] *** avar joined
[10:29] *** avar left
[10:30] *** brrt joined
[10:30] *** avar joined
[10:30] *** avar left
[10:30] *** avar joined
[11:21] *** brrt left
[11:24] *** Altai-man joined
[11:26] *** sena_kun left
[11:28] *** avar left
[11:30] *** avar joined
[11:30] *** avar left
[11:30] *** avar joined
[11:56] *** brrt joined
[12:15] *** zakharyas joined
[12:29] *** mst left
[12:43] *** zakharyas left
[13:21] *** brrt left
[13:54] *** domidumont left
[13:56] *** domidumont joined
[14:06] *** domidumont left
[15:02] <MasterDuke> do all `*->spesh_cand = <foo>` need an MVM_ASSIGN_REf?

[15:07] <MasterDuke> hm, re https://github.com/MoarVM/MoarVM/pull/1344/files#diff-b26a3689b87415a1c76692b9a43a02d7R306 an MVMSpeshGraph isn't an MVMCollectable though

[15:17] *** zakharyas joined
[15:17] *** brrt joined
[15:25] *** sena_kun joined
[15:26] *** Altai-man left
[15:45] <nine> MasterDuke: the spesh graph isn't a collectable, but the references it contains get processed in MVM_spesh_graph_mark

[15:54] *** mst joined
[15:54] *** ChanServ sets mode: +o mst

[15:56] <MasterDuke> so it should be MVM_ASSIGN_REfed?

[16:03] <nine> no

[16:05] <nine> MVM_ASSIGN_REF is for situations where a nursery object may be referred to by a gen2 object. If an object isn't a collectable, it can't be in gen2 either

[16:11] <MasterDuke> right

[16:12] <MasterDuke> nine: did you ever find out why that candidate was getting zeroed in your rr recording?

[16:13] <nine> No, that avenue was pretty fruitless. Auditing the code base gave all the results I've come up with so far

[16:13] <MasterDuke> ah

[16:14] <nine> I mean, it was the objects in spesh slots that got zeroed and I do know that that's simply because they were free'd by the GC when the spesh cands they were referred by was free'd.

[16:15] <nine> So it was clearly due to references to the spesh cands not getting marked

[16:16] <MasterDuke> ok, good to know

[16:34] *** zakharyas left
[16:55] <MasterDuke> that does make debugging tough though, since we're looking for an omission 

[16:57] <MasterDuke> hm. would putting a breakpoint in MVMSpeshCandidate's gc_free and doing a backtrace every time it hits be useful? let's see...

[16:59] *** brrt left
[16:59] <MasterDuke> nope, segv before it's hit

[17:03] <MasterDuke> its gc_mark does get hit, but then we knew that already

[17:19] <MasterDuke> is MVM_spesh_arg_guard_regenerate https://github.com/MoarVM/MoarVM/pull/1344/files#diff-8dfb353347375ceb77fcbe953156c6f6L331 correct?

[17:43] *** brrt joined
[17:56] *** Geth left
[17:59] *** Geth joined
[18:05] <nine> MasterDuke: don't see anything wrong. But it tells me something else: the root checker plugin so far only checks MVMSpeshCandidate* but not MVMSpeshCandidate**

[18:05] <nine> Same for all other collectable types

[19:24] *** Altai-man joined
[19:25] <MasterDuke> nine: changing the list to *just* have a couple relevant `**` types didn't have any 'Missing root's

[19:26] *** sena_kun left
[20:13] *** brrt left
[20:44] *** Altai-man left
[21:49] *** mst left
[23:44] *** mst joined
[23:44] *** ChanServ sets mode: +o mst

[23:49] *** mst left
[23:49] *** mst joined
[23:49] *** ChanServ sets mode: +o mst