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.
00:03 reportable6 joined 00:49 notable6 joined, benchable6 joined 00:50 squashable6 joined 01:32 Kaiepi left 01:33 Kaiepi joined 01:48 Kaiepi left, Kaipi joined, tellable6 joined 01:50 shareable6 joined 01:51 Kaipi left, Merfont joined 01:56 Merfont left 01:58 Kaiepi joined 02:12 Kaipi joined, Kaiepi left 02:48 Kaipi left 02:49 evalable6 joined, sourceable6 joined 03:49 releasable6 joined 04:45 raydiak left, raydiak_ joined 04:48 camelia left, JRaspass left, Nicholas left, bartolin left, bartolin_ joined, JRaspass_ joined, Nicholas joined 04:49 JRaspass_ is now known as JRaspass 06:02 reportable6 left 06:04 reportable6 joined 08:34 linkable6 left, linkable6 joined 08:36 frost joined 09:01 linkable6 left 09:03 linkable6 joined 10:03 raydiak_ is now known as raydiak
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
10:37 sena_kun joined
jnthnwrthngtn OK, thanks for the info :) 10:38
12:02 reportable6 left 12:09 frost left
timo twitter.com/cfbolz/status/1429729528532901889 12:09
12:26 frost joined
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
13:05 reportable6 joined
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
13:10 frost left 15:02 camelia joined
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
16:02 evalable6 left 16:34 linkable6 left 16:36 linkable6 joined
timo you can have all my startup time thank you very much 16:50
17:04 evalable6 joined 17:30 Kaiepi joined
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
18:03 reportable6 left 18:06 sena_kun left 19:07 japhb left 19:34 japhb joined 20:05 reportable6 joined 21:20 japhb left 21:56 japhb joined 23:02 linkable6 left, coverable6 left, unicodable6 left, nativecallable6 left, reportable6 left, evalable6 left, releasable6 left, benchable6 left, squashable6 left, quotable6 left, greppable6 left, notable6 left, shareable6 left, bloatable6 left, sourceable6 left, statisfiable6 left, tellable6 left, bisectable6 left, committable6 left 23:03 committable6 left, reportable6 joined, nativecallable6 joined, coverable6 joined, quotable6 joined, shareable6 joined, greppable6 joined, notable6 joined, linkable6 joined 23:04 committable6 joined, unicodable6 joined, benchable6 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!