| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:33 mst left, mst joined, ChanServ sets mode: +o mst 03:55 avar joined, avar left, avar joined 06:48 rypervenche left, moon-child left, hoelzro left, Altreus left 07:25 moon-child joined, rypervenche joined, hoelzro joined, Altreus joined 07:30 sena_kun joined 08:21 domidumont joined 09:29 leont joined 09:39 avar left 09:46 avar joined, avar left, avar joined 10:29 avar left 10:30 brrt joined, avar joined, avar left, avar joined 11:21 brrt left 11:24 Altai-man joined 11:26 sena_kun left 11:28 avar left 11:30 avar joined, avar left, 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
MasterDuke do all `*->spesh_cand = <foo>` need an MVM_ASSIGN_REf? 15:02
hm, re an MVMSpeshGraph isn't an MVMCollectable though 15:07
15:17 zakharyas joined, brrt joined 15:25 sena_kun joined 15:26 Altai-man left
nine MasterDuke: the spesh graph isn't a collectable, but the references it contains get processed in MVM_spesh_graph_mark 15:45
15:54 mst joined, ChanServ sets mode: +o mst
MasterDuke so it should be MVM_ASSIGN_REfed? 15:56
nine no 16:03
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:05
MasterDuke right 16:11
nine: did you ever find out why that candidate was getting zeroed in your rr recording? 16:12
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
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:14
So it was clearly due to references to the spesh cands not getting marked 16:15
MasterDuke ok, good to know 16:16
16:34 zakharyas left
MasterDuke that does make debugging tough though, since we're looking for an omission 16:55
hm. would putting a breakpoint in MVMSpeshCandidate's gc_free and doing a backtrace every time it hits be useful? let's see... 16:57
16:59 brrt left
MasterDuke nope, segv before it's hit 16:59
its gc_mark does get hit, but then we knew that already 17:03
is MVM_spesh_arg_guard_regenerate correct? 17:19
17:43 brrt joined 17:56 Geth left 17:59 Geth joined
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
Same for all other collectable types
19:24 Altai-man joined
MasterDuke nine: changing the list to *just* have a couple relevant `**` types didn't have any 'Missing root's 19:25
19:26 sena_kun left 20:13 brrt left 20:44 Altai-man left 21:49 mst left 23:44 mst joined, ChanServ sets mode: +o mst 23:49 mst left, mst joined, ChanServ sets mode: +o mst