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 00:08 evalable6 joined 00:46 linkable6 joined 04:06 reportable6 joined 05:31 releasable6 left, bloatable6 left, linkable6 left, notable6 left, greppable6 left, coverable6 left, nativecallable6 left, benchable6 left, squashable6 left, reportable6 left, tellable6 left, committable6 left, unicodable6 left, sourceable6 left, bisectable6 left, quotable6 left, shareable6 left, statisfiable6 left, evalable6 left, reportable6 joined, quotable6 joined 05:32 coverable6 joined, statisfiable6 joined 05:33 greppable6 joined, nativecallable6 joined, shareable6 joined, sourceable6 joined, committable6 joined, notable6 joined, bloatable6 joined, unicodable6 joined 05:34 bisectable6 joined, evalable6 joined 06:02 reportable6 left 06:05 reportable6 joined 06:32 squashable6 joined 06:33 releasable6 joined
nine I did not...anticipate learning so much about pizza before having a coffee when I got up this moarning... 07:20
07:31 linkable6 joined 07:34 tellable6 joined, benchable6 joined 07:49 discord-raku-bot left 07:50 discord-raku-bot joined, discord-raku-bot left, discord-raku-bot joined
nine Now I wonder: don't we need a MVM_SPESH_ANN_DEOPT_INLINE_PRE as well? If we need the distinction, why not on inlined code? 09:53
09:53 frost joined, frost left, frost joined
nine It seems like. Simply attaching the MVM_SPESH_ANN_DEOPT_INLINE annotation to the right instruction actually makes things worse. But when I add an MVM_SPESH_ANN_DEOPT_PRE_INS instead, we get through the build. 10:19
Alas...it doesn't actually fix the original issue :? 10:20
:/
[Coke] ~~ 10:22
nine Oh, it does! I just forgot to re-enable the fix after some testing. 10:25
[Coke] ... did you ever get that coffee? 10:27
nine I did :) 10:28
Ok, half an hour without failure. I delcare victory :) 10:54
timo mhh how long until jnthn gives that first tlk? thats the rakuast one 11:17
i bet he has been working on it in secret during the second 24 hours in the day or something and will blow our minds with some very cool demo that even i couldnt have seen coming 11:18
yeah i basically think of jnthn as a miracle worker. no pressure or anything! 11:19
hm, thats neither helpful nor kind 11:22
nine Well 85 minutes till lizmat++ is on. 11:34
lizmat eh, UTC, so add 120 minutes to that :-)
nine Oooh...good point!
timo phew, a healthy 200 huh. if it were me, maybe that would even be enough to finish my slide deck (which would already have at least 2 slides in it i'm sure) 11:37
12:02 reportable6 left 12:41 frost left 12:59 frost joined, frost left
timo its nice that logging in can get your local timezone in there but it would also be kind of nice if it tried to get that info from your browser and let you just select your timezone by hand 13:00
13:04 reportable6 joined
Geth MoarVM/new-disp: 6b964aeca9 | (Stefan Seifert)++ | 6 files
Fix annotations of inlined graphs landing on the wrong instructions

When creating control flow graphs from existing spesh candidates, we re-create annotations from the information about deopt addresses. These addresses used to point at the spot immediately after the deopting instruction. So to find the instruction the annotation needs to be added to, we need to go to the predecessor of the instruction pointed at. ... (9 more lines)		 13:53
14:54 lizmat_ joined, lizmat_ left, lizmat_ joined 14:58 lizmat left, lizmat_ left, lizmat joined 14:59 squashable6 left
MasterDuke nine: nice, but what does that fix again? a broken spectest? 15:01
nine MasterDuke: it fixes the "Cannot find method 'push_code_object' on object of type Perl6::World" you occasionally got with: while MVM_SPESH_NODELAY=1 ./rakudo-m -c -Ilib t/04-nativecall/02-simple-args.t ; do true ; done 15:17
MasterDuke ah, right
dogbert2 nine++, I'm not sure we're off the hook however 15:43
MoarVM panic: NULL STable in item added to GC worklist
I get it when running t/spec/S17-supply/syntax.t with MVM_SPESH_NODELAY=1, MVM_GC_DEBUG=1 and a 24k nursery 15:46
heh, when compiling with --no-optimize it SEGV's instead 15:50
nine Yes, that's what I see 15:51
(gdb) p ((MVMCallStackPromotedFrame *)record)->frame
$5 = (MVMFrame *) 0xffffffff
dogbert2 nine: I see the same 15:54
I've only tried it once ... but turning off the JIT might 'fix' the problem
nine Running it in rr on the other hand makes it hang 16:02
dogbert2 now timo will be upset :) 16:04
16:07 squashable6 joined
nine I don't think the JIT is to blame 16:15
By disabling some JIT opcodes, I got a different error: 16:16
(gdb) p *(MVMCallStackContinuationTag *)record
$3 = {common = {prev = 0x1ef1918, kind = 6 '\006', orig_kind = 0 '\000'}, tag = 0xffffffff, active_handlers = 0x0}
In a MVMCallStackContinuationTag. Notice that it's still 0xffffffff in the first field after common
dogbert2 are your suspicions pointing in any specific direction 16:23
nine No suspicions yet. The broken record is tc->stack_top->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev->prev 16:32
So it definitely is not the currently processed record :D
16:39 harrow left 16:41 harrow joined
nine Good news is that I can delete the test that makes rr hang and still get the segfault 16:44
It may have something to do with the JIT after all: 16:47
274 tag_record->tag = update_tag;
(rr) bt
#0 0x00007fecc38eadde in MVM_callstack_continuation_append (tc=0x1c91e70, first_region=0x78ae2f0, stack_top=0x78b1d00, update_tag=0xffffffff) at src/core/callstack.c:274
#1 0x00007fecc3904571 in MVM_continuation_invoke (tc=0x1c91e70, cont=0x6f2d9d0, code=0x1c96388, res_reg=0x36ec4ac, insert_tag=0xffffffff) at src/core/continuation.c:164
#2 0x00007feca9a50383 in ?? ()
So MVM_continuation_invoke gets called from JITed code with the apprently bogus insert_tag=0xffffffff
Ah, yes. MVM_continuation_invoke got an additional argument in commit 6516439b91, but the JIT wasn't updated to pass it 16:50
dogbert2 are you saying that the problem is already solved? 17:03
hmm, 6516439b91 is from May, shouldn't we have stumbled upon this problem earlier
[Coke] do we have specific JIT tests other than "the test suite"? 17:06
Geth MoarVM/new-disp: e838c8db75 | (Stefan Seifert)++ | src/jit/graph.c
Fix possible segfaults caused by JIT not supplying an argument

MVM_continuation_invoke got an additional argument in commit 6516439b91, so we need to adapt the JIT implementation of continuationinvoke to do the same. Otherwise we'd end up with an uninitialized value getting dereferenced as a pointer resulting in a segfault.		 17:15
Altai-man nine++ 17:54
[Coke] oooh, will retry on windows. 17:55
18:02 reportable6 left
[Coke] didn't happen to fix my nativecall bugs, ah well 18:56
19:03 reportable6 joined
dogbert2 what do you know, another SEGV 19:09
this time in t/spec/S12-methods/parallel-dispatch.t (test #11) 19:10
run with MVM_SPESH_NODELAY=1, MVM_SPESH_BLOCKING=1, MVM_GC_DEBUG=1 and a 24k nursery 19:11
Thread 1 "moar" received signal SIGSEGV, Segmentation fault. 19:12
lang_meth_call (tc=0x555555559e40, arg_info=...) at src/disp/boot.c:348
348 MVMHLLConfig *hll = STABLE(invocant)->hll_owner;
(gdb) p invocant
$1 = (MVMObject *) 0x0 19:13
nine Yep, got that in rr 19:21
But jnthnwrthngtn++ is currently explaining new-disp :) 19:22
[Coke] crap, going to have to watch it all on repeat! 19:23
dogbert2 Aha. Btw, nice work on the continuationinvoke bug.
nine thanks :)
timo just got finished watching jnthns previous talk
nine I've had a vague or piecemeal understanding of new-disp before, but the talk ties it together nicely 19:24
timo nthis is the birthplace of a lean and mean newdisp debugger machine 19:34
jnthnwrthngtn OK, now I can go on vacation :D 19:43
MasterDuke jnthnwrthngtn++
lizmat jnthnwrthngtn: well deserved! 19:45
nine Oh, we're stumbling over a NULL that gets written to a register by a decont
jnthnwrthngtn: oh, where was that cliff place again? Looks very nice indeed! 19:46
jnthnwrthngtn nine: Lauterbrunnen, Switzerland 19:47
I actaully stay in a village on the top of the cliff (the one on the other side of the valley) 19:48
nine Oh, very nice. Sounds like you're gonna have quite some time to enjoy the train ride, too
jnthnwrthngtn Yes :) 19:49
timo stay safe around that performance cliff :) 19:50
nine If it's a performance cliff...does that mean that you'll fall in slow motion?
jnthnwrthngtn No, just that you'll be pretty slow once you reach the bottom :P 19:55
I *have* seen folks paraglide into the valley. That is probably suitably slow if you know what you're doing :) 19:56
lizmat thought: should the static optimizer be rewritten as a custom compiler pass after RakuAST lands ?
timo should we build a new slang that makes writing the optimizer guts easier? 19:57
i mean were still in nqp for the optimizer and nqp isnt standardised so we could just put it in the officAl grammar 19:59
lizmat new slang? 20:00
20:03 evalable6 left, linkable6 left 20:04 evalable6 joined 20:06 linkable6 joined
nine so decont is innocent, as are the 2 set instructions before it 20:10
It's hllize that turns a BOOTHash into a NULL when it tries to hllize it for nqp 20:11
timo oh that sounds very suspicious indeed 20:14
nine Oh, wait. That's a bogus result. res_reg->o will stay NULL if hllize needs to invoke 20:15
jnthnwrthngtn hllize, another thing that wishes it were a dispatcher... 20:16
nine I was surprised to find the old style invoke there :)
jnthnwrthngtn I wouldn't be sad were it gone upon my return ;)
nine It's a bit hard to track back that NULL since a watch point will only trigger on a change of the data. And writing a 0 into a register that's already 0 won't.
jnthnwrthngtn: so...this is left as an exercise for the reader? :D 20:17
MasterDuke hm, can you pause and write your own data into the register to see if a later write changes it? 20:21
nine It's getting a breakpoint at that earlier place in the same bytecode frame what's hard 20:22
MasterDuke ah
timo break on hllize returning null perhaps? 20:23
MasterDuke lizmat: i think it is in the (eventual) plans to turn the current static optimizer into at least two stages: one for the current error checking it does and one for the actual optimization 20:24
lizmat would we actually still need static optimization? :-) 20:25
timo i imagine thats easier to do in rakuast, since that already has that concept of a "linking" phase that looks up references of different kinds
jnthnwrthngtn nine: Indeed :)
timo the junction syntax transformation i built ages ago is something that would want a static optimizer 20:26
jnthnwrthngtn lizmat: I've thought about gathering info needed for opts during the check phase, and then just emitting better QAST right away :)
Rather than trying it as a QAST transform
lizmat hmmmm
nine jnthnwrthngtn: so...I would npq::hllize would into a desugar that pretty much implements the same cases as the C implementation and guards on the current language and the object's language and remove the C implementation, right? 20:27
lizmat fwiw, things like nqp::for
timo jnthn, is there already a spot where we go from dispatching a method or sub call to deciding we have to autothread junctions?
lizmat I think we could do that more generically from Iterators by providing a special method on the Iterator classes that would basically do the "sink-all" case, but *without* creating the actual Iterator object 20:28
or would you say run time optimization would be able to do that generically
anyways, it's late and you're about to go on holiday... so it can wait a few weeks :-) 20:29
lizmat goes afk&
nine Ha! That broken frame is actually dispatch:<.?>. Looks quite familiar :D
timo fix this issue by throwing out the .? old-style dispatcher and emitting a dispatch op instead instead of debugging further :P 20:35
jnthnwrthngtn timo: For now it's still done in the binder failover, though we might have alternative strategies now 20:38
nine: I guess another option is to do what I did for boot-boolify and to have a lang-hllize dispatcher 20:39
nine: Or some hybrid where lang-hllize delegates to a hllization dispatcher registered by the language, same as the find_method dispatcher
nine jnthnwrthngtn: I think that's on the curriculum for next semester :P
timo i found the spot where the autothread method is callen in dispatchers.nqp 20:40
nine I think, I'm dealing with a deopt issue again 20:42
timo well be hugely in your deobt if you fix this one as well 20:45
maybe ill have an attempt to build the dispatcher implementation of when theres just a single argument thats a junction and see how it would generalize to different positions, different amounts, etc 20:46
nine Well, I'll have an attempt of going to bed :) Visiting parents tomorrow, so won't have much time to debug further. Hopefully on Monday 20:49
jnthnwrthngtn: have a very nice vacation!
timo yeah have a good time both of you. one longer than the other of course 20:51
jnthnwrthngtn Thanks!
Dunno if I'll get time to update the slides page of my site before I leave but jnthn.net/papers/2021-trc-rakuast.pdf and jnthn.net/papers/2021-trc-dispatch.pdf are the slides 20:52
[Coke] (deobt) first of all, how dare you. Second, I wish I could upvote your send. 20:57
moon-child 'CALL-ME($maybe)' haha 21:13
timo so it looks like, from the dispatchers test suite, that a dispatcher program can not just call a bunch of things 21:29
so if i want to do autothreading with dispatchers, i will have to build a little code snippet that can be delegated to that handles the work
then i will want to figure out how work can actually be saved compared to running the full autothread method 21:30
having a bunch of different cases specialcased and dispatching to the right one may be one way
but thats also a lot of code to write, a lot of bytecode to emit, etc 21:32
combinatorial explosion as well 21:33
wait thats what resumption is, right? invoking something else later after your initial target has finished ... well the invoke target has to explicitly ask for the resumption to occur of course 21:58
23:16 evalable6 left, linkable6 left 23:18 evalable6 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!