github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 squashable6 left 00:04 squashable6 joined 00:38 sivoais left 00:43 sivoais joined 00:46 nebuchadnezzar left 06:08 linkable6 left, evalable6 left 06:09 evalable6 joined 06:11 linkable6 joined 07:14 domidumont joined 07:24 nebuchadnezzar joined 08:14 MasterDuke joined 08:47 zakharyas joined 09:32 MasterDuke left 10:13 MasterDuke joined 10:18 Kaiepi joined 10:24 Kaiepi left 10:33 Kaiepi joined
MasterDuke jnthn: immediately after this line github.com/MoarVM/MoarVM/blob/mast...lan.c#L317 here i added `plan_for_deopt(tc, plan, (MVMStaticFrame *)sf);`, where plan_for_deopt looks through the static frame for any candidate with a num_deopts > 100 and if it finds one, calls add_planned. would it be a problem if the same sf is added to 10:45
the plan by both plan_for_sf and plan_for_deopt?
10:53 zakharyas left
jnthn I don't think so, in so far as I think we already can plan multiple things for a single sf anyway 11:00
MasterDuke ok, good, that keeps thing simpler. (though now i have to come up with another theory of what's going wrong) 11:02
11:27 zakharyas joined 11:35 patrickb joined 11:55 zakharyas left 12:32 patrickb left 12:35 MasterDuke left 12:36 MasterDuke joined 12:38 Voldenet left
MasterDuke this seems to be a logic error, because gc_debug, etc don't change anything. gist.github.com/MasterDuke17/fd236...07aad7722f has the current diff (this is after MVMSpeshCandidate has been converted to a repr). the logic is now that deopt.c logs every time a frame is deopted, stats.c increments the counter in the spesh 12:41
candidate, plan.c add a new planned kind to the spesh plan if an updated static frame has a spesh candidate with a count > 100, worker.c calls the new MVM_spesh_candidate_discard_one if it sees the new planned kind
12:44 Voldenet joined, Voldenet left, Voldenet joined
MasterDuke and i'm getting `MoarVM panic: Spesh arg guard: expected 1 candidate but got 2` from the MVM_spesh_arg_guard_regenerate call in MVM_spesh_candidate_add (which i haven't changed any logic of, except to use the new layer of indirection between the spesh body and the candidate list + arg guards 12:45
12:56 sena_kun joined 13:13 zakharyas joined 13:21 MasterDuke left
jnthn Do you only get it if you discard a candidate? 13:21
13:23 MasterDuke joined
MasterDuke jnthn: not sure exactly what you mean, but i get the same error if i stick a `return` right at the top of MVM_spesh_candidate_discard_one 13:25
jnthn OK, what's the minimal addition that causes it? Adding to the plan, for example? 13:26
Hmm, perhaps the error could occur if you have non-unique entries in sf_updated
Make sure that isn't happening also 13:27
Meeting, bbiab
MasterDuke hm, same error if i comment out the call to add_planned in plan_for_deopt
oh, you don't mean just non-unique frames, but frame+candidate? 13:28
because yeah, there are duplicated static frames 13:32
so i should be doing something different here? gist.github.com/MasterDuke17/fd236...patch-L986 13:36
13:45 sena_kun left, sena_kun joined
MasterDuke changing that if + increment + push to just the increment gets a lot farther 14:05
now there's a segfault much later, with an unhelpful backtrace 14:06
in MVM_string_check_arg, 0xEDF6 is not within a mapped region. in 2021 you'd have think we've mapped everywhere... 14:11
well, there was a PEBKAC. i was incrementing the spesh candidate's deopt_count, but adding it to the plan if it's num_deopt was > 100 14:23
fixing that gets further into the nqp build, but now there's another segfault with a different unhelpful backtrace... 14:24
14:53 MasterDuke left 14:54 MasterDuke joined
MasterDuke set GC_DEBUG = 3, now the old friend "Invalid owner in item added to GC worklist" 14:54
15:00 Kaiepi left 15:39 Kaiepi joined 17:08 MasterDuke left 17:47 Altai-man_ joined, sena_kun left 18:09 lucasb joined 18:13 domidumont left 18:36 zakharyas left 19:20 patrickb joined 20:13 MasterDuke joined 20:45 MasterDuke left 20:51 MasterDuke joined
MasterDuke ugh, set a watchpoint on frame->work[i].o in rr, but nothing is jumping out at me when i reverse-cont back to the start 20:52
21:49 patrickb left 22:08 Altai-man_ left