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:20 evalable6 joined
timo why not just put a noop in the "empty" bb :P 00:43
01:20 shareable6 joined 01:40 frost joined 01:50 discord-raku-bot left 01:51 discord-raku-bot joined 03:26 greppable6 left, statisfiable6 left, benchable6 left, sourceable6 left, committable6 left, coverable6 left, nativecallable6 left, notable6 left, releasable6 left, bisectable6 left, linkable6 left, tellable6 left, unicodable6 left, quotable6 left, evalable6 left, bloatable6 left, squashable6 left, shareable6 left 03:27 sourceable6 joined, releasable6 joined, greppable6 joined, benchable6 joined 03:28 quotable6 joined, statisfiable6 joined 03:29 evalable6 joined, bloatable6 joined 03:56 rakuUser left 04:28 squashable6 joined 04:29 coverable6 joined, unicodable6 joined, bisectable6 joined 05:27 linkable6 joined, notable6 joined 05:28 nativecallable6 joined 06:27 tellable6 joined 06:29 committable6 joined 07:28 shareable6 joined 08:03 reportable6 joined
nine The VMNull we're trying to execute comes from sp_getlexstatic_o of &infix:<~> 08:16
Geth MoarVM/store-key_right_shift-differently: 0b713ada14 | (Nicholas Clark)++ | 5 files
No need to pass key_right_shift into `hash_allocate_common`.
MoarVM/store-key_right_shift-differently: a1bb1c30bb | (Nicholas Clark)++ | 10 files
Store `key_right_shift - metadata_hash_bits` in the hashtable.

Instead of storing `key_right_shift` (the shift just the hash bucket) and computing the subtraction each time in `create_loop_state`. This saves one arithmetic operation in a fairly hot function.
MoarVM: nwc10++ created pull request #1534:
Store `key_right_shift - metadata_hash_bits` in the hashtable
Nicholas how many times have I re-read that commit message and failed to spot a missing word?
Geth MoarVM/store-key_right_shift-differently: e5cbede869 | (Nicholas Clark)++ | 10 files
Store `key_right_shift - metadata_hash_bits` in the hashtable.

Instead of storing `key_right_shift` (the shift for just the hash bucket) and computing the subtraction each time in `create_loop_state`. This saves one arithmetic operation in a fairly hot function.
nine sp_getlexstatic_o cannot find &infix:<~> because the frame (DESTROY) apparently does not have a setting. It's outers are <mainline>, <mainline> and that's it 08:35
MasterDuke: I think all in all I like your approach better as it'd e.g. work even in a NativeCall callback. 09:29
I think....I'm not actually chasing a new-disp bug, but a new-disp success. The failing sp_getlexstatic_o is part of Failure's DESTROY submethod which gets inlined into the loop body in finalize_handler. I'd bet that before new-disp we just couldn't pull this off. 09:36
The bug is actually in MVM_frame_find_lexical_by_name which traverses the outer chain but doesn't take inlining into account. 09:40
So we're traversing finalize_handler's outer chain instead, which is indeed rather short (as it's defined in the BOOTSTRAP) 09:41
I do wonder though why MVM_frame_find_lexical_by_name doesn't use the frame walker, contrary to MVM_frame_find_lexical_by_name_rel_caller which does. 09:44
dogbert11 nine++, impressive detective work 11:13
nine While changing MVM_frame_find_lexical_by_name to use the framewalker (via MVM_frame_lexical_lookup_using_frame_walker) fixes this one issue, I get tons of new test failures due to failures to resolve lexicals now. 11:29
12:02 reportable6 left 12:03 reportable6 joined
nine Sometimes it only gets weirder... I'm now running both methods of finding lexicals and break if I get a different result. At such a point we're executing an sp_getlex_no. But this op does not appear in the output of MVM_dump_bytecode(tc) 12:11
Oh, the output seems to be broken in general. The section containing the sp_getlex_no seems to be garbled. 12:14
12:26 frost left
dogbert11 another rabbit hole it seems :) 12:31
nine Indeed. The bytecode dumper simply hasn't been told about sp_runbytecode and sp_runcfunc yet 12:35
Trying to teach it now, but it's a bit of a slow learner
jnthnwrthngtn I think I did teach it about dispatch at some point, so can probably steal that. 12:37
12:37 rakuUser joined
jnthnwrthngtn I always forget the bytecode dumper is also usable on specialized code when debugging. 12:37
Geth MoarVM: 0b713ada14 | (Nicholas Clark)++ | 5 files
No need to pass key_right_shift into `hash_allocate_common`.
MoarVM: e5cbede869 | (Nicholas Clark)++ | 10 files
Store `key_right_shift - metadata_hash_bits` in the hashtable.

Instead of storing `key_right_shift` (the shift for just the hash bucket) and computing the subtraction each time in `create_loop_state`. This saves one arithmetic operation in a fairly hot function.
MoarVM: 619370662a | (Jonathan Worthington)++ (committed using GitHub Web editor) | 10 files
Merge pull request #1534 from MoarVM/store-key_right_shift-differently

Store `key_right_shift - metadata_hash_bits` in the hashtable
12:46 frost joined 12:48 frost left
nine jnthnwrthngtn: I've split MVM_spesh_disp_create_dispatch_op_info into MVM_spesh_disp_dispatch_op_info_size and MVM_spesh_disp_initialize_dispatch_op_info to make it usable outside of spesh and have replaced the custom code in the bytecode dumper with it. 13:10
This also fixes the buffer overrun that was still there 13:11
Aaaah....looks better, works better :) 13:21
13:22 MasterDuke90 joined
MasterDuke90 any objections to merging github.com/MoarVM/MoarVM/pull/1532 and then bumping? 13:24
nine MasterDuke: just approved 13:29
MasterDuke90 cool, i'll merge, bump, and make the necessary nqp+rakudo changes 13:31
Geth MoarVM: 5ead9f0d40 | (Daniel Green)++ | 3 files
Respect --full-cleanup in nqp::exit

If --full-cleanup was passed, but we are exiting via an nqp::exit call, still do the cleanup. To do this we need to know in the interpreter if
  --full-cleanup was in fact passed, so add a flag to MVMInstance for it.
MoarVM: 4b7ffe3af4 | MasterDuke17++ (committed using GitHub Web editor) | 3 files
Merge pull request #1532 from MasterDuke17/respect_full-cleanup_in_exit_op

Respect --full-cleanup in nqp::exit
nine So the frame walker things we are in an inlinee, when the spesh log says that the current instruction definitely is not
That's why with the frame walker it doesn't find the lexical anymore 13:33
MasterDuke90 btw, didn't you do some other fix not too long ago where you converted some custom frame walking code to use the frame walker?
nine MasterDuke: yes, that was backtrace
MasterDuke90 ah, right 13:34
nine So, we have a bug with the fix for the bug exposing another bug with the debugging of this bug exposing a bug in the debugging aid. 13:35
.oO(Why couldn't I just have a look at the codegen bug instead?!)
Run it with JIT disabled, they said. Reduces complexity they said. The JIT actually got this right! It does check if we're asking for the currently executing frame and gives the right deopt_idx. 13:52
MasterDuke90 re-write it all in rust. that'll solve all our problems, right? 13:55
14:06 MasterDuke90 left
nine Oh, apparently the JIT doesn't get it right either :/ 14:29
I think that would require something like a MVM_jit_code_set_current_position whenever we come out of an inlined code region 14:33
Geth MoarVM/new-disp: 3130e52633 | (Stefan Seifert)++ | 4 files
Handle sp_runbytecode and sp_runcfunc in bytecode dumper

As a side effect, this also fixes a buffer overrun when dumping bytecode with dispatch ops with more than 8 arguments.
[Coke] keeps misreading "runbytecode" as having a "ruby" in it. 15:21
15:50 linkable6 left, evalable6 left 16:52 evalable6 joined
japhb keeps reading "runcfunc" as sounding like "runk-funk" 17:50
timo same
17:52 linkable6 joined 18:02 reportable6 left 18:03 reportable6 joined
[Coke] mmm 18:49
nine LOL I thought I was the only one 19:02
19:04 MasterDuke68 joined
MasterDuke68 nine: gist.github.com/MasterDuke17/ecfd2...48f7b2a7ba has the catchsevg output from the two recent fails in moarvm's ci 19:05
nine Looks like NativeCall callbacks really need some good GC testing 19:06
timo any workloads we have that use lots of callbacks? GUI stuff with gtk i assume at the very least 19:14
MasterDuke68 so far it's not trivially reproducible 19:24
which makes me glad we added catchsegv to our ci, it at least points us somewhere 19:27
nine: do you have OBS set up to use catchsegv? 19:31
anyone else have problems building with clang when MVM_GC_DEBUG is set to 2? 19:35
oh, just finished, but took about 5m alone on src/jit/x64/emit.o 19:36
.ask Nicholas did you see my question on github.com/MoarVM/MoarVM/pull/1481 ? 20:07
tellable6 MasterDuke68, I'll pass your message to Nicholas
22:02 MasterDuke68 left 22:47 Altai-man left, Altai-man joined 22:50 discord-raku-bot left, discord-raku-bot joined 23:24 rakuUser left