|
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
|
|||