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:05 [Coke] joined 04:33 unicodable6 left, evalable6 left, releasable6 left, benchable6 left, quotable6 left, notable6 left, bloatable6 left, squashable6 left, shareable6 left, greppable6 left, nativecallable6 left, coverable6 left, bisectable6 left, statisfiable6 left, sourceable6 left, committable6 left
Nicholas good *, #moarvm 06:17
07:19 AlexDaniel left, uzl[m] left, psydroid left, crystalfrost[m] left 07:24 AlexDaniel joined
lizmat Good * from NL as well 07:28
07:28 psydroid joined, uzl[m] joined, crystalfrost[m] joined
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
08:46 MasterDuke left
lizmat jnthnwrthngtn nine ^^ 08:47
08:52 sena_kun left 08:53 sena_kun joined 10:07 sena_kun left 10:08 sena_kun joined
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
11:05 psydroid left, uzl[m] left, AlexDaniel left, crystalfrost[m] left
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
12:49 AlexDaniel joined 12:59 psydroid joined, uzl[m] joined, crystalfrost[m] joined 14:56 ggoebel left 15:00 ggoebel joined 16:08 MasterDuke joined
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
17:28 sena_kun left 17:29 sena_kun joined
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
17:51 sena_kun left 17:52 sena_kun joined
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
20:34 finanalyst joined 22:42 finanalyst left 23:40 raiph joined 23:41 raiph left