Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
japhb Looks like Inline::Perl5 is failing tests with a lot of VMNull errors ... is that known? 00:04
japhb (I don't see an issue for it, but that doesn't mean nine doesn't already know about it.) 00:07
I was building a Rakudo from this afternoon: rakudo-moar-2021.10-91-g4c238bdc9 00:08
nine japhb: wasn't aware of that, no 08:50
Nicholas good *, #moarvm 08:51
timo good good 08:59
Nicholas moin moin 09:00
timo aww, new-disp-nativecall has merge conflicts 09:04
with replace-attrinited
oh it's supposed to be the -libffi one 09:05
Nicholas I'm probably mostly AFK until likely Monday evening, so please don't assume that I can answer questions promptly. 09:07
I hope that there aren't questions. :-)
nine Oh darn, new-special-return also broke one of Inline::Perl5's tests. t/p5_object_destructor.t dies either with Internal error: Unwound entire stack and missed handler" in an unwind from a nested runloop or a slot < cache->num_entries assertion failure/segfault in getlexstatic_o 12:04
lizmat meh 12:10
nine Huh.... it's a JIT issue. Breaks with MVM_JIT_EXPR_DISABLE=1 but works with MVM_JIT_DISABLE=1 12:12
jnthnwrthngtn Sigh. I lost the better part of a week on keeping finalizer on same thread semantics for the sake of Inline::Perl5. :/ 12:49
At least if it's only a JIT issue then it's probalby not that the whole approach is busted in some way 12:52
I wonder if something somewhere is not syncing up the JIT state
dogbert17 tries to 'bisect' the bug in complex.t 13:20
nine maybe new-special-retiurn just uncovered some preexisting issue 13:42
dogbert17 at least new-special-retiurn isn't the cause of the error in complex.t 13:48
jnthnwrthngtn nine: Also possible. The getstaticlex_o was is utterly weird, I can only imagine we're in a really confused state for that to happen 13:55
Shopping, bbl
nine won't be getting significant hacking time today. Short notice family visit 15:28
dogbert17 phew, that took some time, but it seems as if the error (possibly GC related) is caused/revealed by commit github.com/MoarVM/MoarVM/commit/43...0a470f2d1a 16:53
the error I'm talking abouth is this one gist.github.com/dogbert17/93fc8512...ce49522baa 16:54
perhaps jnthnwrthngtn, or anyone else for that matter, can see if anything obvious sticks out in that commit 16:57
timo are bbs not meant to be emptied by remove_ins? 18:58
i now also realize: when i just throw out instructions, the registers read by them will be marked unneeded, unless they are already "used by deopt" for the same spot 19:01
and i'll have to be careful for deopt annotations anyway, so i don't mess things up royally in some other way :D 19:02
this was not a "nice little saturday evening project"
timo to elaborate, i'm looking backwards from any dispatch that has been "never dispatched" for the first bb that is a branch 19:08
so that the whole code from there could be chopped off, and the branch instruction replaced with a conditional deopt
the thought behind it is that branches that haven't been run at all so far are handlers for exceptional conditions that are unlikely to be taken any time soon, so reducing the size of the bytecode can help inline it into more frames if it goes below the size limit 19:10
nine timo: oh, certainly a worthwhile pursue. But not one I'd have figured to be a litte evening project :) 19:46
jnthnwrthngtn dogbert17: I'd think it enables further inlining and so maybe revealed something, alas. 21:14
Geth MoarVM: MasterDuke17++ created pull request #1600:
Fix MVM_string_ascii_encode_substr to use given offset value
22:24