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:02 reportable6 left 00:05 reportable6 joined 00:59 vrurg left 01:10 kjp left 01:20 vrurg joined 02:20 evalable6 left, linkable6 left 02:23 linkable6 joined 03:00 Xliff_ left 04:14 frost joined 04:21 evalable6 joined 05:58 linkable6 left, quotable6 left, nativecallable6 left, bisectable6 left, releasable6 left, notable6 left, bloatable6 left, unicodable6 left, evalable6 left, statisfiable6 left, greppable6 left, shareable6 left, benchable6 left, squashable6 left, committable6 left, sourceable6 left, reportable6 left, tellable6 left, coverable6 left, releasable6 joined 05:59 notable6 joined, unicodable6 joined, coverable6 joined, nativecallable6 joined 06:00 benchable6 joined, greppable6 joined, committable6 joined, squashable6 joined 06:01 tellable6 joined, bisectable6 joined 06:04 reportable6 joined 06:58 quotable6 joined 07:00 linkable6 joined 07:01 sourceable6 joined 07:21 dogbert17 left 07:29 dogbert17 joined 07:59 evalable6 joined, shareable6 joined 08:15 dogbert17 left
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
09:15 evalable6 left, linkable6 left 09:17 linkable6 joined 09:24 dogbert17 joined
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
10:00 bloatable6 joined, statisfiable6 joined 10:02 raydiak left
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
11:17 evalable6 joined 12:03 reportable6 left 12:05 reportable6 joined 12:06 squashable6 left 12:08 squashable6 joined
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.
12:46 squashable6 left
MoarVM: niner++ created pull request #1568:
Fix segfault finding dynamics after deopt		 12:47
13:21 frost left
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
14:21 linkable6 left, evalable6 left, evalable6 joined 14:45 patrickb joined 14:47 squashable6 joined 15:47 evalable6 left 16:03 colemanx joined 16:27 Kaiepi left, Kaiepi joined 17:21 linkable6 joined 17:24 Kaipi joined 17:25 Kaiepi left 17:28 Kaipi left, Kaipi joined 17:32 Xliff joined
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
17:48 evalable6 joined
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 )
18:03 reportable6 left 18:06 reportable6 joined
Xliff Huh! 18:28
So you pun the role directly to the Attribute and it works? 18:29
18:55 Kaipi left, Kaipi joined
Geth MoarVM/master: 7 commits pushed by (Daniel Green)++, MasterDuke17++ 19:01
19:06 sena_kun left, sena_kun joined 19:10 Merfont joined, Kaipi left 19:18 Kaipi joined, Merfont left 19:32 linkable6 left 19:35 linkable6 joined 19:42 Merfont joined, Kaipi left 19:47 Kaipi joined 19:48 Merfont left 20:09 patrickb left 20:25 Kaipi left, Kaipi joined 20:27 Merfont joined, Kaipi left 21:19 Merfont left, Merfont joined 22:19 evalable6 left, linkable6 left 22:22 colemanx left 22:59 Merfont left 23:00 Merfont joined 23:20 linkable6 joined 23:21 Kaipi joined 23:22 Merfont left 23:49 Merfont joined 23:50 Kaipi left 23:58 Merfont left

Powered by Cro and the Raku® Programming Language.

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

Thank you!