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:06 reportable6 left 00:08 reportable6 joined 00:10 Geth left 00:11 Geth joined, lizmat joined, RakuIRCLogger joined 00:56 vrurg_ left, vrurg joined 02:14 RakuIRCLogger left 03:14 bisectable6 left, evalable6 left, notable6 left, reportable6 left, benchable6 left, bloatable6 left, sourceable6 left, releasable6 left, linkable6 left, statisfiable6 left, quotable6 left, unicodable6 left, coverable6 left, nativecallable6 left, squashable6 left, greppable6 left, tellable6 left, committable6 left, shareable6 left, releasable6 joined, quotable6 joined, coverable6 joined 03:15 unicodable6 joined, bloatable6 joined, bisectable6 joined, benchable6 joined 03:16 shareable6 joined, nativecallable6 joined 03:17 statisfiable6 joined 03:38 frost joined 04:14 evalable6 joined 04:15 notable6 joined 04:16 linkable6 joined, tellable6 joined 04:21 frost left 04:27 frost joined 05:14 sourceable6 joined 05:16 greppable6 joined, committable6 joined 05:17 squashable6 joined 07:07 reportable6 joined 08:11 Shane__ left 09:23 Geth left, Geth joined 10:24 RakuIRCLogger joined 11:40 Geth left, Geth joined 11:42 frost left 11:44 Geth left, Geth joined 12:07 reportable6 left 12:08 reportable6 joined 13:25 statisfiable6 left, bisectable6 left, releasable6 left, nativecallable6 left, benchable6 left, reportable6 left, bloatable6 left, greppable6 left, shareable6 left, squashable6 left, unicodable6 left, committable6 left, coverable6 left, linkable6 left, quotable6 left, sourceable6 left, evalable6 left, notable6 left, tellable6 left, committable6 joined 13:26 squashable6 joined, bloatable6 joined, nativecallable6 joined, greppable6 joined 13:27 quotable6 joined, reportable6 joined 13:28 releasable6 joined, coverable6 joined, statisfiable6 joined 14:26 bisectable6 joined, linkable6 joined 14:27 sourceable6 joined, shareable6 joined, unicodable6 joined, tellable6 joined 15:16 Shane__ joined
nine I've made some progres on "No such private method 'SET-SELF' on Map". Looks like it's a frame walker/multi level inlining issue. Apparently at the current position where we look up ::?CLASS, we are multiple inlining levels deep. When looking for the correct inlined frame for the current position, we take the first, but at least in this case, the last matching one would be more appropriate. 15:17
15:27 notable6 joined
dogbert11 so you have now found a reliable way to repro the problem? 15:32
nine Not really reliable. Depends a lot on timing and I'm pretty sure hash order to end up with the right stack of inlinees. But at least I cought one gdb run in my net 15:33
I added a check to MVM_frame_find_lexical_by_name which abort()s if we find ::?CLASS in one of Map's methods. 15:34
dogbert11 so there's something wrong with the logic which retrieves the correct frame then? 15:42
nine Yes. I hope simply reversing the direction of search will be all that's required. But it'll take quite a bit of code reading to confirm that 15:54
An open question is if this only affects JITed code or if it could also happen in interpreted code. 16:04
Huh...if I read merge_graph correctly, we already add an inlinee's inlines to the inliner's inlines table before adding an entry for the inlinee itself. I.e. those indexes should already be ordered in a way to have the most nested first. With this, just looking for the first matching entry in ascending order would be correct. 16:12
So why doesn't this work in this case?
Just got the failure with disabled JIT, which is unsurprising, considering my finding ^^^ 16:13
Aaaah I've got it! 16:31
What happens is: we inline Map.keys which is just: Seq.new(Rakudo::Iterator.Mappy-keys(self)). Originally the spesh cand for keys does not have any inlines, so none can get stacked up front. 16:32
After inlining we run optimize_bb over the inlined graph to get a more optimized version. optimize_bb will then encounter those dispatches, try to optimize them and succeed at inlining. But those inlinees get added to the table after the original inlinee for keys. 16:33
So when we're looking for ::?CLASS, we'll find keys first, even though we really are in Mappy-keys. 16:34
This is a new-disp regression. Before, spesh was smart enough, not to try to inline calls in code we've just inlined: github.com/MoarVM/MoarVM/commit/bc...ca0edR2701 16:35
This protection got lost in translation.
lizmat nine++ 16:41
17:08 linkable6 left
nine 40 minutes without failure in the configuration that reproduced the issue pretty reliably in a minute or two. I think this fix may just work :) 17:15
dogbert11 nine++ 17:45
Geth MoarVM: 059c013b09 | (Stefan Seifert)++ | src/spesh/optimize.c
Fix frame walker finding wrong value after multi level inlining

The frame walker expects a spesh cand's inlinees to be sorted depth first. This has the benefit of the walker being able to just iterate over the inlinees and take the first one that covers the current bytecode position.
In the failing case we'd inlined Map.keys which is just: ... (20 more lines)		 17:57
lizmat will do the bump 17:58
nine thanks :)
18:08 reportable6 left
MasterDuke nine++ nice one. whereas the nqp build is actually getting sigkilled when i try to use the new sp_getarg_u i added... 18:12
18:28 evalable6 joined, benchable6 joined 20:09 reportable6 joined, linkable6 joined
Geth MoarVM/master: 4 commits pushed by (Vittore F. Scolari)++, niner++ 20:24
lizmat bumpy time again ? 20:25
Geth MoarVM: 596b42154f | (Daniel Green)++ | 4 files
Add an MVM_nativecall_encode_string function

And have MVM_nativecall_unmarshal_string just call it with the right arguments. This lets us use MVM_nativecall_encode_string in some other NativeCall code that was partially duplicating the functionality in MVM_nativecall_unmarshal_string.		 20:31
MoarVM: 4bf970a9df | (Daniel Green)++ | 3 files
Fix potential invalid free in nativecall

When using mimalloc this particular memory comes from libc's malloc(), so we have to use libc's free().
MoarVM: 278a705ebc | MasterDuke17++ (committed using GitHub Web editor) | 4 files
Merge pull request #1673 from MasterDuke17/fix_potential_invalid_free_with_mimalloc_in_nativecall
MasterDuke how about now 20:32
lizmat ok! 20:36
20:42 sena_kun left 20:43 sena_kun joined
lizmat bumped 20:54
MasterDuke nice 21:24
22:24 [Coke] left 22:29 [Coke] joined
Geth MoarVM: MasterDuke17++ created pull request #1681:
Fix spesh of named uint parameters		 22:47
23:41 discord-raku-bot left, discord-raku-bot 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!