github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke do all `*->spesh_cand = <foo>` need an MVM_ASSIGN_REf? 15:02
hm, re github.com/MoarVM/MoarVM/pull/1344...3a02d7R306 an MVMSpeshGraph isn't an MVMCollectable though 15:07
nine MasterDuke: the spesh graph isn't a collectable, but the references it contains get processed in MVM_spesh_graph_mark 15:45
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
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
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 github.com/MoarVM/MoarVM/pull/1344...56c6f6L331 correct? 17:19
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
MasterDuke nine: changing the list to *just* have a couple relevant `**` types didn't have any 'Missing root's 19:25