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.
vrurg m: use nqp; my $*INVISIBLE := nqp::null(); say $*INVISIBLE; 02:37
camelia Dynamic variable $*INVISIBLE not found
in block <unit> at <tmp> line 1
vrurg ^^^ unavoidable error because there is no way to distinguish a missing symbol from one bound to VMnull. In either case nqp::getlex* family returns VMnull. 02:40
timo probably the only way to make a dynamic variable inaccessible to callee frames? 08:22
Nicholas good *, #moarvm 08:56
nine good comma, *! 09:01
MasterDuke wow, new-disp leaks quite a bit according to valgrind 09:12
Nicholas how much of this is the spesh thread? 09:13
MasterDuke a bunch i think, lots of the output has translate_dispatch_program and MVM_spesh_disp_optimize in the backtrace 09:14
tbh, i wasn't trying to check new-disp, i was looking for those hashes that are sticking around to put in a gist for you 09:15
Nicholas I wasn't *sure* about this (haven't checked carefully) but I *thought* that at MoarVM exit nothing waits for the spesh thread, so whatever it was doing just gets dropped, instead of it gettign to finish and tidy up. 09:16
nine Yes, spesh is only cleaned up with --full-cleanup 09:17
MasterDuke fwiw, this was with --full-cleanup
Nicholas and in turn, --full-cleanup sometimes seems to hit aborts or assertion failures (IIRC)
nine Then it's legit
Nicholas oh, righty
MasterDuke and of course the only example i can find now is the one that segfaults during vm destruction, so can't use it 09:21
jnthnwrthngtn moarning o/ 09:38
dogbert17 something is wrong when running t/02-rakudo/reproducible-builds.t with MVM_SPESH_NODELAY=1 10:46
No such method 'checksum' for invocant of type 'Any'
in block <unit> at t/02-rakudo/reproducible-builds.t line 31
running with a small nursery leads to a SEGV
==377319==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fe651c5273a bp 0x7fe64e211550 sp 0x7fe64e211370 T1) 10:47
#0 0x7fe651c52739 in optimize_runbytecode src/spesh/optimize.c:1445
#1 0x7fe651c551f0 in optimize_bb_switch src/spesh/optimize.c:2249
jnthnwrthngtn dogbert17: Hmm, what does line 1445 contain? 11:03
dogbert17 1443 /* If the target static frame is not invoked or has no specializations, 11:05
1444 * give up. */
1445 if (target_sf->body.instrumentation_level != tc->instance->instrumentation_level)
1446 return;
jnthnwrthngtn huh, how can there be a null pointer, right above there's a check if target_sf is NULL and we return if so 11:06
dogbert17 perhaps I have messed something up, let me double check ...
jnthnwrthngtn If you have it in the debugger, please p target_sf 11:07
Geth MoarVM/new-disp: 04079e21e5 | (Jonathan Worthington)++ | 2 files
Extract "is this a code handle" check
 11:08
MoarVM/new-disp: 27f0a39d10 | (Jonathan Worthington)++ | 4 files
Fill out mechanism for bytecode calls from C

So that we can start to migrate the final things away from the legacy invocation mechanism.
MoarVM/new-disp: 72e129155b | (Jonathan Worthington)++ | src/6model/containers.c
Migrate code_pair container spec to new convs
jnthnwrthngtn 25 ->invoke( left to go 11:10
MasterDuke i guess tc or tc->instance could be NULL? 11:15
dogbert17 jnthnwrthngtn: if only it was so easy :) running gdb hangs the test, all threads are waiting for better times it seems
dogbert17 in fact, this is starting to feel like something for nine, perhaps this is the same problem he started looking at yesterday 11:17
i.e. if MVM_SPESH_NODELAY=1 and the nursery is small then some tests suddenly fail to compile
jnthnwrthngtn MasterDuke: If it is, something is incredibly hosed. 11:31
I did touch runbytecode yesterday; I can quite imagine I broke something. But...I'm confused about this ASAN output ;)
*:)
dogbert17 it is very strange, if I remove ASAN the SEGV is gone but we're left with a compilation error instead 11:43
Geth MoarVM/new-disp: d701fee1da | (Jonathan Worthington)++ | src/6model/containers.c
Migrate value/desc container to new convs
 12:12
Geth MoarVM/new-disp: 152ed1e2e5 | (Jonathan Worthington)++ | 3 files
Migrate type parameterizer call to new convs
 13:01
MoarVM/new-disp: 18cb9081f8 | (Jonathan Worthington)++ | 3 files
Migrate bind error handler to new convs
MoarVM/new-disp: 4d1320a0ac | (Jonathan Worthington)++ | 2 files
Migrate thread start to new convs
dogbert17 jnthnwrthngtn: don't forget to grab a cup of coffee from time to time 13:13
jnthnwrthngtn Think I did enough coffee today, the next cup will be tea :) 13:20
dogbert17: btw, I think it might have been you who (years ago) suggested I try springbank whisky. Finally, while on vacation last week, I did so. 13:21
(And it's good, so if it was you, thanks!) 13:22
Geth MoarVM/new-disp: e75a70d061 | (Jonathan Worthington)++ | 2 files
Migrate continuation invokes to new convs
 13:39
jnthnwrthngtn Down to 15 uses of ->invoke(...) now, and 3 of them are in hll.c and nine++'s work on hllize moving over to the dispatcher should eliminate those 13:40
Geth MoarVM/new-disp: 2cb4af1fda | (Jonathan Worthington)++ | 3 files
Migrate exception invokes to new convs
 13:56
jnthnwrthngtn Ah, debugserver has a commented out usage, so that's easy :) 14:04
dogbert17 jnthnwrthngtn: I don't remember if that suggestion came from me but I do like Springbank. In fact, I have some 15yo left in a bottle. I bought it in a small town named Bowmore :) 14:14
Geth MoarVM/new-disp: 1cb2abe1ab | (Jonathan Worthington)++ | 4 files
Migrate exit handler invokes to new convs
 14:30
MoarVM/new-disp: 13cb19be10 | (Jonathan Worthington)++ | 3 files
Migrate finalize handler invoke to new convs
MoarVM/new-disp: eae94d526b | (Jonathan Worthington)++ | 2 files
Migrate native lib restore to new convs
 14:52
jnthnwrthngtn Hm, the native callback thing is going to need some care 15:27
Well, really just needs unwrapping code objects 15:28
Geth MoarVM/new-disp: 0cf5360c3b | (Jonathan Worthington)++ | 4 files
Migrate native callback invocation to new convs
 15:51
jnthnwrthngtn Just 6 ->invoke(...)s left 15:55
3 of which are I think all hllize, 2 related to type checking, which I need to figure out an overall solution for, and 1 related to the debug server, which I'll have a look at now 15:56
jdv what happens when that goes to 0? i assume that's the immediate goal...
jnthnwrthngtn jdv: A bunch of code supporting the legecy calling conventions and invocation protocol gets removed 15:58
And in turn, all call frames get a bit smaller, various temporary legacy/new-disp branches go away so we don't pay for them, etc. 15:59
nine: fwiw, I think I've concluded that the special return mechanism will go away post-merge, since it doesn't really get in the way of anything, even if it'd be nice to see the back of it. 16:04
(And it's not even really going away, I guess, just becoming a different kind of callstack record) 16:05
Geth MoarVM/new-disp: a3763f5400 | (Jonathan Worthington)++ | 3 files
Migrate debug server invoke to new convs

This also fixes a potential args buffer overrun in the current implementation.		 16:26
MoarVM/new-disp: 7965608e25 | (Jonathan Worthington)++ | src/debug/debugserver.c
Remove commented code
 16:28
MoarVM/new-disp: f0f5eb998a | (Jonathan Worthington)++ | src/6model/reprs/MVMCFunction.c
Remove MVMCFunction invoke handler

Everything that relied upon it is gone.		 16:37
dogbert17 todays stupid new-disp question: aren't this line and the one following at odds with each other? github.com/MoarVM/MoarVM/blob/new-...am.c#L2360 16:49
jnthnwrthngtn dogbert17: oops, yes, that looks like copy paste 16:51
Geth MoarVM/new-disp: 91e5ca5087 | (Jonathan Worthington)++ | src/disp/program.c
Fix copy-pasto

Spotted by dogbert++.		 17:06
MoarVM/new-disp: d7f9d4abdf | (Jonathan Worthington)++ | 6 files
Remove invocation handler support

The entire invocation protocol will go away in the near future, but this piece already can.
MoarVM/new-disp: c75199ee37 | (Jonathan Worthington)++ | 8 files
Eliminate now-unused with_invocant field

This makes every MVMCallsite a pointer smaller.
MoarVM/new-disp: a8710f2ace | (Jonathan Worthington)++ | 10 files
Remove further legacy multi caching leftovers
 17:22
jnthnwrthngtn Enough for now 17:31
dogbert11 jnthnwrthngtn++ 17:35
nine Intriguing: the setting build failure I got yesterday after my attempted fix goes away with MVM_SPESH_DISABLE 19:10
nine Seems like it's hllizefor that's broken. hllize by itself looks fine 19:53
Meanwhile the evidence gets stronger for the lang_hllize dispatcher needing that MVM_disp_program_record_guard_concreteness. Without it setting compilation fails with the same STable-where-an-object-should-be issue. 20:17
Though to be honest, I don't understand why. lang_hllize itself doesn't actually care about concreteness. It doesn't even really care about the object's type. It only cares about the object's language. We guard on the type just because the type tells us which language.
So nqp::hllize(SomeType) and nqp::hllize(SomeType.new) will always have the same result of the lang_hllize dispatcher. So why the need to guard on concreteness? 20:19
The raku-hllize dispatcher does care about concreteness and adds an appropriate guard: nqp::dispatch('boot-syscall', 'dispatcher-guard-concreteness', $arg);
jnthnwrthngtn nine: Does the translation of the dispatch program into ops look correct? 20:43
nine How can I check? 20:44
Ah, of course there's DUMP_ defines 20:45
jnthnwrthngtn Yeah, you can get at the original dispatch program that way, though also if you look at the spesh log, does it have facts or guards to justify reading an attribute, etc. 20:46
(I think you said this was about a mis-read of an attribute...)
It's weird though, since pretty much every method and multi dispatch also ends up with attribute reads etc. 20:47
nine Yes, I get a class_handle in get_attribute that's pointing at an STable instead of an MVMObject 20:49
nine That it's a get_attribute that's failing tells me though, that we must have deopted. In the speshed frame, there's no getattr_o anymore. It was replaced by sp_get_o 20:53
Gotta catch some sleep. Maybe I'll get further tomorrow 21:01
timo good luck 21:04
dogbert11 src/core/callsite.c:5:70: warning: excess elements in struct initializer 21:28
5 | static MVMCallsite zero_arity_callsite = { NULL, 0, 0, 0, 0, 0, 0, 0 };
I guess this is benign, btw there are more of them
jnthnwrthngtn ah, yeah, I guess that's a missed leftover from removing the with_invocant field 21:52
Geth MoarVM/new-disp: 052f2da143 | (Jonathan Worthington)++ | src/core/callsite.c
Remove init of removed callsite field

And also fix some NULL/0 inconsistency		 21:57
jnthnwrthngtn dogbert11: That should nail 'em all 21:58
A callgrind on CORE.setting compilation gives 344,563,041,195 for new-disp now; master is 330,702,914,420. Closing in.
And I still didn't figure out the missing spesh stats thing yet 21:59
Um, wait, what...the latest callgrind output I'm looking at has us doing less frame invocations than on master?! 22:05
That's...unexpected. 22:07
dogbert11 that sounds like good news :) 22:20
btw, all struct initializer errors have indeed been fixed 22:21

Powered by Cro and the Raku® Programming Language.

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

Thank you!