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:02 reportable6 left 01:02 releasable6 left, bloatable6 left, greppable6 left, sourceable6 left, committable6 left, benchable6 left, squashable6 left, tellable6 left, bisectable6 left, coverable6 left, nativecallable6 left, unicodable6 left, shareable6 left, notable6 left, evalable6 left, linkable6 left, statisfiable6 left, quotable6 left 01:03 greppable6 joined, bisectable6 joined, notable6 joined, statisfiable6 joined 01:04 releasable6 joined 01:05 nativecallable6 joined, quotable6 joined, bloatable6 joined, squashable6 joined, shareable6 joined 02:03 reportable6 joined 02:04 coverable6 joined, benchable6 joined, evalable6 joined 02:05 unicodable6 joined
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
02:50 Util_ left 04:04 committable6 joined 05:03 tellable6 joined 05:36 frost joined 06:02 reportable6 left 06:03 sourceable6 joined 06:04 linkable6 joined 07:01 dogbert17 joined 07:02 dogbert11 left 07:27 dogbert11 joined 07:30 dogbert17 left
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
09:20 dogbert17 joined
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
09:23 dogbert11 left, dogbert11 joined 09:26 dogbert17 left 09:28 dogbert17 joined 09:30 dogbert11 left 09:38 dogbert11 joined
jnthnwrthngtn moarning o/ 09:38
09:41 dogbert17 left 09:57 dogbert11 left, dogbert17 joined
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
11:03 reportable6 joined
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
11:14 cognominal joined
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
11:16 cognominal_ left
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
11:22 Kaiepi joined
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
12:02 reportable6 left
Geth MoarVM/new-disp: d701fee1da | (Jonathan Worthington)++ | src/6model/containers.c
Migrate value/desc container to new convs
 12:12
12:56 MasterDuke left 12:59 cognominal left
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
13:25 frost left 13:27 cognominal joined
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
16:05 reportable6 joined
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
16:58 dogbert11 joined 17:00 dogbert17 left
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
18:02 reportable6 left 18:03 reportable6 joined 18:12 dogbert11 left, dogbert11 joined 18:22 dogbert11 left, dogbert17 joined 18:34 dogbert11 joined 18:36 dogbert17 left 18:51 dogbert11 left 18:58 dogbert11 joined
nine Intriguing: the setting build failure I got yesterday after my attempted fix goes away with MVM_SPESH_DISABLE 19:10
19:23 TempIRCLogger left, TempIRCLogger joined 19:34 TempIRCLogger left 19:35 TempIRCLogger joined
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
20:52 TempIRCLogger left, TempIRCLogger joined
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
21:52 evalable6 left, linkable6 left 21:55 linkable6 joined
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
22:42 jgaz joined 22:52 evalable6 joined 22:58 jgaz left 23:02 squashable6 left 23:04 squashable6 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!