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.
Nicholas [* GOOD *] 05:38
japhb o/ 05:40
nine \o 06:22
Geth MoarVM/disp-bytecode-size: b1109f043b | (Elizabeth Mattijsen)++ | src/disp/syscall.c
Use MasterDuke's suggestion
12:11
Geth MoarVM: cc49dcf935 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/disp/syscall.c
Attempt at implementing a "bytecode-size" dispatch

As suggested by jnthn: irclogs.raku.org/moarvm/2022-06-12.html#11:30
12:24
jnthn lizmat++ 12:57
lizmat I was wondering if I should generalize that dispatch into a more general frame introspection mechanism?
nine jnthn: I've come across a bit of an issue in RakuAST. my $native_trait := multi trait_mod:<is>(Routine $r, :$native!) { ... } will actually bind the proto instead of the multi candidate, because in github.com/rakudo/rakudo/blob/raku...umod#L1037 we generate a lexical lookup instead of a closure clone. Why do we do that there? Apparently we can't decide that on the scope alone, 13:00
lizmat I was specifically thinking about cuuid name outer
nine but how else?
lizmat I wouldn't be surprised if that code was a first approximation to get things working? 13:01
jnthn lizmat: I'd probably do individual calls for the different things rather than building up a data structure of multiple pieces, since it will be hard to EA away stuff created inside of syscalls 13:04
lizmat jnthn: I was more thinking along an extra parameter indicating what stuff you'd want 13:05
jnthn And syscalls in the MoarVM sense - unlike those in the OS sense - are cheap. Spesh can even lift the type/repr check out if there is a sequence of calls that validate that.
lizmat ok, so multiple calls it is then
jnthn lizmat: I think that's still harder opt wise
nine Cheap to call and also cheap to implement
lizmat okidoki, just more code, but I can live with that :-) 13:06
jnthn nine: Why is IMPL-EXPR-QAST involved in traits at all?
Oh, sorry, misread 13:07
I'm not sure why it's not just always self.IMPL-CLOSURE-QAST($context)
Try it and see, I guess 13:09
nine Ha! Indeed. Now that was easy :) 13:19
lizmat hmmm.. it appears bytecode-size is constant, even if stuff gets inlined into it? 14:04
nine Yes, you are reading the _static_ frame's bytecode size 14:11
lizmat I guess the actual size is not kept anywhere ? 14:16
also: why is cuuid a string, when it only has numeric values afaics
nine The actual size of what exactly?
lizmat of the bytecode after it has inlined stuff 14:17
in it
I mean, that's the purpose of inlining, isn't it ?
nine The bytecode of what?
lizmat of the frame 14:18
m: sub a() { }; dd &a.bytecode-size
camelia 20
nine That would be the static frame
lizmat ah... ok, I think it's starting to click... optimizations only work on clones of the static frame ? 14:19
nine Inlining happens during specialization, the result of which is specialized bytecode. For every static frame there can be an arbitrary number of specialized bytecodes which are picked at runtime.
So the only question that makes sense to ask that would touch size after inlining is "what's the bytecode size of a given frame _on the callstack_?" 14:21
lizmat ack... 14:22
going to think about that over some cycling&
japhb nine: I'm not sure that's the only useful question. For example, you might want to get the collection of specialized bytecodes for a given static frame, and do some analysis across the set. (The value of that of course increasing the more you can inspect about each bytecode) 14:31
nine That's a "yes, but". I'm not sure, we'd want to expose so much about internals. Spesh is an implementation detail after all 14:33
japhb Well, fair enough. And I certainly wouldn't make it a Raku feature ... or even Rakudo or NQP. But it seems like the kind of thing that someone optimizing for MoarVM might reasonably want to know, so being able to introspect it on some debugging interface at least seems useful. (Whether that be the literal debug server, or via syscalls that are explicitly for low-level work only.) 14:37
nine When invoking 37 'parameterize', provided outer frame 0x32c22b0 (1329 'IMPL-STUB-CODE') does not match expected static frame 0x3d6c160 (45 '') 17:27
Ah, of course!
[Coke] Glad we could help! ;) 17:56
lizmat so I'm thinking about how one would be able to find out the language level with which a given Callable (well, technically a Code) was compiled 20:06
I've gotten as far as this: MVMString *language_level = ((MVMCode *)obj)->body.sf->body.cu->body.mainline_frame 20:08
only thing needed is to look up CORE-SETTING-REV in that stash, right?
I guess something like ...mainline_frame->body.lexical_names_list somehow? 20:10
nine There's a lexical_names hashmap and a lexical_names_list array 20:13
I do wonder though: what do you need this information for?
lizmat well... I guess it can be very handy to know when you get a Callable at which language level it was compiled 20:17
and decide on things to do after that ?
and being able to dispatch on language level would also be very helpful, I think?
nine But the VM doesn't care about such things? It rarely even distinguishes between NQP and Raku 20:18
lizmat are you implying there would be an easier way to find out the language level of a given Callable / Code object ? 20:20
nine No, I just don't understand why you'd need that inside MoarVM 20:21
lizmat well, I would create a Code.language-level method that would do the correct nqp::dispatch
agree we don't need it inside MoarVM... but outside? 20:22
nine That's a different question :) And one that doesn't involve the VM 20:23
lizmat please enlighten me :-) 20:24
nine "Language version" is a concept that the VM does not know at all. That's handled completely in high level code and it should be kept that way. Luckily dispatch is also done purely by high level code. So you don't have to change the VM in any way to achieve language version dependent dispatching. 20:26
lizmat except for being able to find out the language version of a given Callable ? 20:27
because until I grokked the syscall functionality, I didn't see a way for that 20:28
nine Wouldn't that just require adding an attribute to Code and setting the appropriate value at compile time? 20:32
lizmat wouldn't that add a lot of overhead? 20:33
but an interesting idea
or perhaps add it @!compstuff 20:34
*to
nine @!compstuff is cleared after compilation
lizmat so is that a yes or no for adding it after compilation? 20:35
nine Compared to how much data is in a Signature, which every Code object has, a single attribute doesn't sound like much
lizmat ok, fair enough... will sleep over it... afk&
nine You can't use @!compstuff
jnthn Please don't use @!compstuff, it'll either be repurposed or hopefully tossed out by the RakuAST-based compiler frontend. 21:46
If there's a $!flags field it may be possible to `+|` them onto that, but then it'd be a pain for guarding potentially 21:47
lizmat I will not use @!compstuff 21:55
:-)