| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:04 patrickz joined 00:08 patrickb left 00:14 patrickz left 01:23 AlexDani` joined 01:24 AlexDaniel left 01:32 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 02:29 lucasb left 02:45 vesper11 left, Guest38485 left 02:46 Guest38485 joined, vesper11 joined 04:54 squashable6 left 04:55 squashable6 joined 07:10 domidumont joined
Geth MoarVM/fix_deopt_all_in_native_callback: 18d378fc57 | (Stefan Seifert)++ | 9 files
08:56 sena_kun joined 09:21 zakharyas joined 09:22 patrickb joined 09:32 zakharyas left 09:34 zakharyas joined 10:14 zakharyas left 10:25 zakharyas joined 10:53 sena_kun left 11:07 sena_kun joined 12:36 lucasb joined 12:37 zakharyas left 12:54 sena_kun left 13:08 sena_kun joined 13:40 squashable6 left 13:41 squashable6 joined 13:49 zakharyas joined 14:24 zakharyas left 14:25 zakharyas joined 14:27 zakharyas left 14:28 zakharyas joined 14:39 zakharyas left 14:41 zakharyas joined 14:53 sena_kun left 15:07 sena_kun joined
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
16:19 domidumont left 16:22 zakharyas left 16:44 patrickb left 16:53 sena_kun left
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
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
17:08 sena_kun joined
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
17:43 domidumont joined, domidumont left 18:54 sena_kun left 19:08 sena_kun joined 20:53 sena_kun left 21:09 sena_kun joined 22:43 sena_kun left 22:44 brrt joined
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
23:53 brrt left