github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
colomon Is there any current-ish Raku literate programming module? Perl6::Literate claims to not be very serious and is years out of date, the better one that README references doesn’t look like it’s been touched in a decade… 04:16
nine jnthn: what you described was the original bug. I could easily see that in rr which showed me that deopt was clearing spesh_cand and effective_spesh_slots. This time the current frame never had those. 08:22
tellable6 2019-12-11T23:54:00Z #raku-dev <patrickb> nine Never mind.
hey nine, you have a message: gist.github.com/7610b6a070da795fab...cddb1948a9
nine Oh, the frame got moved by the GC! That's why the watch point for its spesh_cand doesn't trigger in reverse-cont 20:44
And yes, it's deopt all again. So it seems like I need to do similar fixes for JIT compiled frames as I've already done for interpreted ones 20:46
nine So, how does this work in the first place when we're in a JIT compiled frame and we invoked something and that causes a deopt all. How does the JIT compiled code know to exit to the interp? 20:59
nine Well, a deoptall on an inactive frame may only happen during an invoke which already has a lot of special handling in the JIT. Handling which nativecallinvoke lacks. 21:26
So I guess what's needed is for the JIT to generate code that after a nativecallinvoke checks if the frame actually still has a spesh_cand and exit to the interp if not, i.e. a somewhat manual deopt. 21:28
I really wonder if the same issue exists with nativeinvoke_o. It should 21:31
I still don't know how exactly the JIT returns to the interpreter after a deopt in an invoke. But at least I have an idea on what's missing, even if I don't know yet how exactly that needs to look like. 21:36