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.
jnthnwrthngtn moarning o/ 10:06
jnthnwrthngtn is back from vacation
lizmat jnthnwrthngtn o/ 10:10
jnthnwrthngtn So, did y'all finish new-disp while I was gone? :) 10:11
Nicholas \o 10:14
"y'all" - no. Just a couple of heros worked on it. (I'm no hero) 10:16
lizmat jnthnwrthngtn: some glitches got fixed :-) 10:22
jnthnwrthngtn :) 10:23
oh wow, I see nine++ did turned hllize into a dispatcher :) 10:28
dogbert11 nine++ has made stellar work but he claimed that one bug required your intervention :) 10:29
and that is github.com/MoarVM/MoarVM/issues/1529 10:30
jnthnwrthngtn OK, thanks for the info :) 10:38
timo twitter.com/cfbolz/status/1429729528532901889 12:09
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/08/23/2021-34-stabler/ 12:29
nine jnthnwrthngtn: welcome back! hllize was a cool endeavour. When I got into the implementation, your remarks made more and more sense and indeed, they turned out to be the only sensible way (I could find). 12:55
jnthnwrthngtn: if you're happy with the result, I can mop up the remains. There's just one place where we emit hllize ops directly in p6argvmarray. Then I think we can remove the old implementation. 12:57
jnthnwrthngtn: the open question for issue #1529 is really "what was the game plan here for concurrent dispatch runs at the same callsite?" 12:59
jnthnwrthngtn timo: hah, sounds like something I put into new-disp just recently :)
nine: Whoever installs first wins, whoever loses just throws away their dispatch program after unwind. 13:00
nine I've noticed that part, yes.
timo is there something we're missing in new-disp related to OSR? i just tried "for ^100_000_000 {}" and the dispatch_v ops both say "never dispatched", though it's possible my local new-disp is not clean 13:01
jnthnwrthngtn nine: We may throw away some things that are valuable, but the majority of sites are monomorphic
nine The tricky bit seems to be memory management of inline cache entries as free at safepoint just doesn't seem to be enough
timo then we get loads and loads and loads of "statistics updated" with <unit> racking up millions of OSR hits. the stats themselves are empty: no interned callsite, callsite hits: 1, osr hits: milions, maximum stack depth: 10 13:02
jnthnwrthngtn nine: Yes, I made a mistake, it seems 13:03
When I introduced the "are we megamorphic" thing, which seems to be involved in the stack traces you posted
What I shoulda done is calculate the "how morphic are we" number at the *start* of the dispatch program recording 13:04
Rather than doing it lazily later
jnthnwrthngtn I guess my thinking was "we often won't check it", but...we can't assume that we can look at what the IC entry we read poitns to at any point other than when we initially set up the dispatch and there's not a safepoint 13:05
So moving the "how morphic" calculation should do it 13:06
Geth MoarVM/new-disp: c524ad32d5 | (Jonathan Worthington)++ | 2 files
Don't follow dangling inline cache pointer

The "how morphic is this callsite" implementation used the inline cache entry that we observed before recording a dispatch program. However, in a multi-threaded program, this may have been freed due to a callsite transition in another thread before the dispatch program is recorded. Resolve this by pre-calculating the inline cache size before we start, since it's very a cheap thing to do anyway. Resolves #1529; nine++ for excellent diagnosis.
15:07
jnthnwrthngtn nine: I see: 15:17
+ MVMROOT(tc, capture, { /* keep capture alive when allocating the new one */
+ capture = MVM_disp_program_record_capture_drop_arg(tc, capture, 1);
+ });
But I think that's over-cautious; MVM_disp_program_record_capture_drop_arg should internally keep it alive
Also 15:19
Add gettypehllrole op to facilitate writing hllization code in HLLs
I've preferred adding such things via the syscall mechanism (and think we may in the future want to move more ops, such as I/O ones, to work in that way) 15:20
nine jnthnwrthngtn: ah, indeed, MVM_capture_drop_arg takes care of that 15:21
So, kinda no new ops at all? 15:23
jnthnwrthngtn Also about "Bring hllize tests into the dispatcher world" in NQP - the JVM backend doesn't have the dispatch mechanism
nine oh darn
jnthnwrthngtn I've so far been careful to try and keep the tests in t/nqp/ generic 15:24
(I think :))
nine Is there a way to compile those parts of the tests conditionally?
jnthnwrthngtn No, I've broken tests out into t/moar/ and t/jvm/ instead when needing to do such backend-specific things 15:25
nine I guess having two copies of those hllize tests isn't that terrible
jnthnwrthngtn In Rakudo, `+ if ($spec) {` is a Perlism :-)
That's all the things I spot. 15:26
nine I'm feeling confident that I can fix those :D 15:27
jnthnwrthngtn Yay 15:28
Then I guess we get to rip out the hllize/hllizefor ops
And the invoke behind them
nine Looking forward to that :)
dogbert11 if you continue like this we'll soon be out bugs :) 15:30
Nicholas jnthnwrthngtn: is there any "documentation" about the difference (in intent) between syscalls and ops - ie why should one be used and not the other? My guess is "syscalls are for implementation details needed for just this VM" and "OPs are things that all VMs that support NQP should provide" but I don't remember it being spelled out like that
timo syscalls can be declarative about their requirements in terms of types and concreteness, can't they? 15:31
nine In case of gettypehllrole it's just following 2 pointers, so not much to analyze or optimize. And there's the symmetry with settypehllrole. 15:32
timo and that allows spesh to generate guards that can then be tossed out if the requirements are known to be met
jnthnwrthngtn I think a lot of nqp::foo that exists today should come to compile into syscalls.
In general, I think ops should be for things that are either 1) really primitive (without object args, for example), or 2) really common 15:33
And the rest can be migrated to boot-syscall. 15:34
As timo mentioned, anything we interpret today that checks what types we give it and then calls some C code is a good candidate for syscall 15:35
Because we stand a chance of eliminating those type checks, which we can't today (or we do but it's ad-hoc)
I'd also like the C function dispatch terminal to JIT into a C call in most cases 15:36
So the syscalls should further evolve so there's a "real" impl and an "unwrapping VM args" impl
(the latter delegating to the former) 15:37
So eventually the boot-syscalls will mostly JIT into calling C functions that just do the work without knowing anything about MoarVM calling conventions, after any guards we coudln't eliminate 15:38
At some point, we may well get down to having a rather small number of ops, at which point we might think about a new bytecode formart that is 8-bit things, not 16-bit things
Which'd be good cache wise
And maybe let us have a more efficient interpreter too
timo and one or two small syscalls can become a little snippet of exprjit, too, if we think "inlining" the logic can be worth it 15:39
or is that more for real opcodes?
jnthnwrthngtn timo: I've considered that some syscalls could register a "I can do even better!" function also :) 15:40
I'm wondering if `decont` should actually be a dispatch in disguise also
timo it does definitely call code in some cases 15:41
jnthnwrthngtn Yeah, and today we can't optimize those
(Proxy)
Probably that one is for after new-disp is merged 15:42
nine I wonder where the next immediate speedups on new-disp will come from? 15:52
jnthnwrthngtn Still need to re-instate spesh linking and inlining for Raku multi sub and method calls 15:53
Only NQP ones are handled at the moment (Raku ones needs awareness of potential resumption) 15:54
Also, need to go through invocation and clear up/streamline a bunch of things
For example, the special return mechanism should go away in favor of a callstack record, so we won't have an extra check for that on every return 15:55
The ->work is meant to live in the frame callstack record also now
But still not moved
nine Oooh...I will be so sad to see special return gone. Not :D
jnthnwrthngtn Well, the mechanism stays, just...not like that :)
Although some more current users of it will also go away 15:56
The main thing I'm still mulling over is what becomes of `istype` and the things behind it
Any non-trivial cases bottom out in type_check or accepts_type 15:57
And today we never get to inline or spesh-link those
And that's another place using special_return, and the legacy method caches that need to go away 15:58
yeah, the debug server is the only other user of legacy method caches 16:00
So we're really close to getting rid of those too
And then we can stop publishing them
And thus not calculate/serialize/deserialize them
Which should get us something off startup
timo you can have all my startup time thank you very much 16:50
Geth MoarVM/new-disp: 0dacb04214 | (Stefan Seifert)++ | src/disp/boot.c
Remove overly cautious MVMROOT

MVM_capture_drop_arg takes care to keep capture alive while allocating the result capture, so we don't have to.
17:38