github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:00 moon-child joined 00:06 dogbert2 joined 00:08 dogbert17 left 00:20 sivoais left 00:21 sivoais joined 03:07 squashable6 left 03:09 squashable6 joined 08:19 domidumont joined 08:28 MasterDuke joined
MasterDuke . 08:47
tellable6 2021-01-19T23:27:21Z #moarvm <jnthn> MasterDuke Sorry, was afk/distracted for quite a while. Yes, sounds reasonable.
MasterDuke jnthn: no worries, i'd gone ahead with doing that 08:53
hm. in stat.c i added `case MVM_SPESH_LOG_DEOPT: { if (e->deopt.spesh_cand->body.deopt_count++ > 100) MVM_repr_push_o(tc, sf_updated, (MVMObject *)e->entry.sf); break; }`. but in plan.c where it's looping over the updated_static_frames, i won't have the spesh candidate 09:01
09:19 mst joined, ChanServ sets mode: +o mst 09:31 zakharyas joined
jnthn MasterDuke: No, but you can walk over the candidates to see which of them are over the limit? 10:03
e.g. for each frame, look at its candidates and see if any are good for removal?
MasterDuke oh, right. they all are attached to the static frame
10:08 domidumont1 joined 10:10 domidumont left 10:26 MasterDuke left
nine geth down? 11:22
github.com/MoarVM/MoarVM/commit/79...c918b5674d
Fix size calculation of VMArray's (read|write)_buf when elem_size > 1
11:59 travis-ci joined
travis-ci MoarVM build passed. Stefan Seifert 'Fix size calculation of VMArray's (read|write)_buf when elem_size > 1 11:59
travis-ci.org/MoarVM/MoarVM/builds/755334225 github.com/MoarVM/MoarVM/compare/2...d0e3749ac2
11:59 travis-ci left 12:26 zakharyas left 12:42 MasterDuke joined
MasterDuke heh. in worker.c `/* Implement the plan and then discard it. */ <...> for (i = 0; i < n; i++) { MVM_spesh_candidate_add(tc, &(tc->instance->spesh_plan->planned[i])); GC_SYNC_POINT(tc); }` that's the opposite of what i want to do! 12:46
jnthn Yup, prior to now plans only specified things to add :) 12:48
nine the plan giveth, the plan taketh away... 13:25
13:32 zakharyas joined 14:03 MasterDuke left 14:36 MasterDuke joined
MasterDuke this is a new one: `MoarVM panic: Spesh arg guard: expected 1 candidate but got 2` 14:58
jnthn With luck, an internal sanity check that will save some even more tedious debugging... 15:15
The arg guard is much less terrifying than it used to be
I used to try and tweak it in place
Once I got to doing derived specialations I realized I wasn't smart enough to implement that, and just regenerated it from the candidates. 15:16
Well, it wasn't exactly in place, but it was "a cheap memcpy and then update the copy"
MasterDuke i sort of remember you making that change. of course i have no idea why that's happening. the code calling regenerate hasn't really had any change to the number of candidates called with at that point (i think) 15:18
17:20 sena_kun joined 17:37 domidumont1 left 17:54 japhb left 17:58 MasterDuke left 18:23 japhb joined 19:07 sena_kun left 19:34 zakharyas left 20:10 patrickb joined 20:26 MasterDuke joined 21:02 MasterDuke left 21:59 patrickb left