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.
Nicholas good *, #moarvm 06:17
lizmat Good * from NL as well 07:28
lizmat I think I found another race condition that can segfault, at an unexpected, yet rather hot place: 07:29
github.com/rakudo/rakudo/blob/mast...bs.pm6#L52
aka nqp::atkey(GLOBAL.WHO,$pkgname) and nqp::atkey(PROCESS.WHO,$pkgname)
spotted with: MoarVM oops: MVM_str_hash_fetch_nocheck called with a stale hashtable pointer
at SETTING::src/core.c/stubs.pm6:38
so it looks like we're going to need a lock on DYNAMIC :-( 07:30
or provide a threadsafe interface to fetching values from GLOBAL.WHO / PROCESS.WHO 07:31
meh... I guess this should be extended to all Stashes 08:29
and by consequence also to all ContainerDescriptors that initialize hash entries 08:36
lizmat jnthnwrthngtn nine ^^ 08:47
jnthnwrthngtn Well, we've already declared that one shouldn't expect Hash to be threadsafe, so I don't see it as *that* general a problem. Workflows invovling stashes arguably do need something. 10:11
lizmat like dynamic variables ? 10:14
m: dd PROCESS.WHO.^name 10:15
camelia "Stash"
lizmat but apparently when compiling 6.d setting, PROCESS.WHO is a BootHash 10:16
is that some kind of HLLization going on ?
using Stash.$!lock.protect on Stash.AT-KEY and using that in DYNAMIC fails with: Method 'AT-KEY' not found for invocant of class 'BOOTHash' 10:17
nine Huh....I thought we had already solved that DYNAMIC initialization problem 11:47
lizmat made it less likely, but still not 100% 11:56
it's very rare, only been able to make it crash that way once
nine Ah, that was INITIALIZE-DYNAMIC which we made thread safe 12:06
At least we are going to need that lock only when accessing dynamics that are registered in GLOBAL or PROCESS 12:08
lizmat FWIW, I found a small race condition in Stash.ASSIGN-KEY, but the fix breaks things, so going to look at it again after finishing the weekly
nine I wonder why getdynlex is marked :noinline. It is using the frame walker, so I figure it should be safe to inline. Maybe we just didn't remove the marker when switching the implementation to the frame walker? 12:10
lizmat inlining DYNAMIC would be a good win 12:11
jnthnwrthngtn nine: I think the situation was that it started looking one caller out, and to do that it wanted a ->caller to get the starting point 12:13
If that's no longer the case and it uses frame walker from the current location then it probably can be relaxed 12:14
lizmat fwiw, could someone explain why the body of src/Perl6/BOOTSTRAP/EXPORTHOW.nqp is run at each Rakudo startup ? 12:15
nine MVM_spesh_frame_walker_init(tc, &fw, cur_frame, 0); 12:22
return MVM_frame_getdynlex_with_frame_walker(tc, &fw, name);
lizmat: can you please test MoarVM's inlineable_getdynlex branch? 12:29
MasterDuke nine: on inlinable_getlexdyn i get `+++ Compiling   gen/moar/stage1/MASTOps.moarvm 16:10
Missing infixish operator precedence at line 1085, near " $value un"
   at gen/moar/stage2/NQPHLL.nqp:1059  (src/vm/moar/stage0/NQPHLL.moarvm:panic)
 from gen/moar/stage2/NQPHLL.nqp:1317  (src/vm/moar/stage0/NQPHLL.moarvm:EXPR)` when building nqp
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/03/28/2022-...admapping/ 16:52
timo danluu.com/cgroup-throttling - interesting 17:30
for moarvm maybe mostly "make sure we're aware of cpu counts in container situations"; just today i stumbled upon a postgres that had been configured to use 16x as much ram as it has available, because assumedly the tuning tool saw only the host memory size, not what the container / cgroup had 17:47
timo > The .NET runtime has had adaptive thread pool sizes for a decade, one of the many ways the .NET stack is more advanced than what we commonly see at trendy tech companies 19:42
lizmat timo: it is my understanding that MoarVM asks libuv about number of cores, and that libuv does the right thing wrt containers 20:10
timo that sounds very good already! 20:13

Powered by Cro and the Raku® Programming Language.

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

Thank you!