github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM/fix_deopt_all_in_native_callback: 18d378fc57 | (Stefan Seifert)++ | 9 files
WIP
08:50
nine So...I got rid of those hangs in tests, and now there's only a single test file failing with a segfault, albeit one in JIT compiled code 15:24
Guest38485 sounds like progress 15:27
nine So, I looked at the disassembly of the place where that segfault occurs and tried to match it to blocks generated by the lego JIT. Looks like it's blowing up in a get_spesh_slot macro because tc->cur_frame->effective_spesh_slots (which ends up in rdx) is NULL 17:03
That's why it blows up in mov rdx,QWORD PTR [rdx+0x48] 17:04
jnthn Is tc->cur_frame->spesh_cand set?
nine So it's quite possible that this is another deopt issue
spesh_cand is 0 17:05
dinner&
jnthn Yeah, sounds like it somehow remained in the JIT code after a deopt
Rather than leaving the JIT code
nine jnthn: in case you didn't follow in the past week: this whole thing started because I discovered an issue with deopt all in nested runloops (NativeCall callbacks) 17:06
jnthn No, was on a trip so couldn't really follow closely 17:11
nine Long story short: the deoptimization didn't really propagate out of the nested runloop, leading to exactly what I'm now seeing: getspeshslot failing due to a NULL effective_spesh_slots. I added a couple of hacks and got it to work without the JIT, fixed up a couple of JIT issues and this is now the last one 17:30
brrt \o 22:44
brrt wonders if nine is aware of the stack-manipulation mechanism that makes the JIT return to the interpreter 22:45
... and I note that the pointers we maintain for that assume a non-nested runloop 22:47