|
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`. |
08:19 | |
| 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 |
08:21 | ||
| 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. |
08:22 | |
| 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`. |
12:41 | |
| 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. |
15:00 | |
| [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
|
|||