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.
lizmat hmmm... I just noticed that just starting "raku" and letting it sit in the repl, grows at about 2MB / minute 09:09
raku -e 'sleep' does not do that, but that doesn't have the supervisor thread running 09:10
so it feels to me the supervisor thread itself is leaking
sadly a --profile of sitting in the REPL for a while, does not produce a HTML file that has something deciperable 09:14
apart from the fact that for the 42 seconds it ran, it did 6 garbage collections 09:15
nine Any full collections? 09:30
lizmat no 09:35
"There were 0 full collections involving the entire heap."
nine Then it might not be an actual leak, but simply objects making it into gen2 which keeps growing until one of the thresholds for a gen2 collection is reached 09:37
lizmat but how can it be growing if the supervisor thread is supposed not to be allocating anything? 09:40
timo i did measure recently that it does allocate some closure clones or something 09:44
lizmat also: spectest does appear to still be significantly slower :-( 09:47
it's been a while since I regularly ran spectests, but: 09:52
Files=1349, Tests=117859, 616 wallclock secs
is a value for wallclock I have never seen on my machine
lizmat git revert fbb5228e8ed0e566 33296d406511557a2b6 --no-commit 10:04
brings this back to:
Files=1349, Tests=117859, 357 wallclock secs
timo i wonder what RMD would say about this 10:13
lizmat a lot, probably :-) 10:21
in any case: github.com/rakudo/rakudo/pull/4577
nine Since that commit was a correctness fix, I'd hesitate to revert it. No point in delivering a wrong result faster 10:22
lizmat Well, I'd like to see it reverted before the 2021.10 release, to give us more time to figure out what causes the spectest slowdown 10:23
Geth MoarVM/fix_segfault_finding_dynamics_after_deopt: bce19e6663 | (Stefan Seifert)++ | 5 files
Fix segfault when thread deopts while another tries to find a dynamic

Commit e94893f897495f3de16d4898279c87e356058acb fixed a possible segfault in the frame walkercaused by a concurrent deopt in a different thread. The fix was to use a local copy of the frame's spesh_cand pointer. However MVM_spesh_deopt_find_inactive_frame_deopt_idx which is called by the same code also accesses the frame's spesh_cand. So this function could still end up ... (5 more lines)
12:46
MoarVM/fix_segfault_finding_dynamics_after_deopt: e1e9acac86 | (Stefan Seifert)++ | src/spesh/frame_walker.c
Fix segfault in frame walker when other thread clears the frame's extra

Similar to another thread clearing a frame's spesh_cand leading to issues fixed in commit bce19e6663aba5e32f2b6e1a8b8c1a2856b70f6a, it's also possible that another thread clears a frame's extra, right after we checked it for non-NULL and before we try to dereference it.
Fix by taking a local copy of the pointer before we check and dereference it.
MoarVM: niner++ created pull request #1568:
Fix segfault finding dynamics after deopt
12:47
Geth MoarVM/fix_segfault_finding_dynamics_after_deopt: 74c35679a3 | (Stefan Seifert)++ | 5 files
Fix segfault when thread deopts while another tries to find a dynamic

Commit e94893f897495f3de16d4898279c87e356058acb fixed a possible segfault in the frame walkercaused by a concurrent deopt in a different thread. The fix was to use a local copy of the frame's spesh_cand pointer. However MVM_spesh_deopt_find_inactive_frame_deopt_idx which is called by the same code also accesses the frame's spesh_cand. So this function could still end up ... (5 more lines)
13:32
MoarVM/fix_segfault_finding_dynamics_after_deopt: 80f8edf947 | (Stefan Seifert)++ | src/spesh/frame_walker.c
Fix segfault in frame walker when other thread clears the frame's extra

Similar to another thread clearing a frame's spesh_cand leading to issues fixed in commit 74c35679a3fba707ad695c53c28918aca30b95b5, it's also possible that another thread clears a frame's extra, right after we checked it for non-NULL and before we try to dereference it.
Fix by taking a local copy of the pointer before we check and dereference it.
nine CI found an editing mistake that only showed up in non-JITed code 13:33
Xliff I am getting the following from Raukdo: "lang-call cannot invoke object of type 'VMNull' belonging to no language" 17:34
Is this a new-disp error?
Geth MoarVM/new-disp-nativecall: 9 commits pushed by (Stefan Seifert)++ 17:36
nine Xliff: can't tell from that message alone 17:37
Xliff: the message is new-dispish, but the condition could just as well have led to a different error message (something like "Cannot invoke an object of type VMNull") before. 17:38
Xliff nine: I have a small program that invokes it. Would that help? 17:46
m: role IdentityAttibute { }; multi sub trait_mod:<is> (Attribute $attr, :$identity-data-store!) is export { $attr does IdentityAttribute; }; class A { has $!a; has $!b is identity-data-store; }
camelia 5===SORRY!5=== Error while compiling <tmp>
lang-call cannot invoke object of type 'VMNull' belonging to no language
at <tmp>:1
timo i can not speak for nine, but i assume "yes" 17:47
nine On 2021.08 this gives: Cannot invoke this object (REPR: Null; VMNull)
timo interesting, i wonder how that does not explode in any ecosystem modules already 17:48
its not because of private vs public attributes i assume
nine Huh: 17:57
m: multi sub trait_mod:<is> (Attribute $attr, :$identity-data-store!) is export { $attr does role IdentityAttribute { }; }; class A { has $!a; has $!b is identity-data-store; }
camelia ( no output )
Xliff Huh! 18:28
So you pun the role directly to the Attribute and it works? 18:29
Geth MoarVM/master: 7 commits pushed by (Daniel Green)++, MasterDuke17++ 19:01