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.
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
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
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 :)
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
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
lizmat bumped 20:54
MasterDuke nice 21:24
Geth MoarVM: MasterDuke17++ created pull request #1681:
Fix spesh of named uint parameters		 22:47

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!