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:03 reportable6 joined 00:09 ggoebel joined 00:29 ggoebel left 00:37 ggoebel joined 00:50 ggoebel left 01:30 ggoebel joined 02:11 ggoebel left 02:30 ggoebel joined 02:42 colemanx joined 02:52 ggoebel left 03:52 evalable6 left, linkable6 left 04:52 greppable6 left, quotable6 left, benchable6 left, notable6 left, shareable6 left, statisfiable6 left, nativecallable6 left, releasable6 left, bisectable6 left, bloatable6 left, coverable6 left, committable6 left, unicodable6 left, sourceable6 left, tellable6 left, squashable6 left, reportable6 left 04:53 reportable6 joined, evalable6 joined, quotable6 joined 04:54 tellable6 joined, bloatable6 joined, notable6 joined 04:55 benchable6 joined, releasable6 joined, statisfiable6 joined, bisectable6 joined, shareable6 joined 05:53 greppable6 joined, linkable6 joined 05:54 nativecallable6 joined, squashable6 joined 05:55 unicodable6 joined 06:02 reportable6 left 07:23 nebuchadnezzar joined 07:40 MasterDuke left 07:45 patrickb joined 07:53 committable6 joined, sourceable6 joined 07:55 MasterDuke joined
Geth MoarVM/new-disp-nativecall: d09757817a | (Stefan Seifert)++ | src/core/nativecall_dyncall.c
Fix segfaults when primitive parameters are passed to native function

The dispatcher calling convention allows for unboxed values to get passed to a native function. Need to handle those in MVM_nativecall_dispatch instead of blindly assuming that we always get objects.		 07:59
MasterDuke heh. i set a watchpoint on spesh_cand->body.jitcode when i hit the segfault. then i reverse-continued. `Old value = (MVMJitCode *) 0xffffffff00000005`, `New value = (MVMJitCode *) 0x5`. somehow neither of those value strike me as correct... 08:00
nine where does it get written_ 08:03
MasterDuke MVM_sc_set_collectable_sc
nine And it's quite possible that it gets overwritten multiple times.
That sounds like it got freed and the memory gets reused.
08:03 reportable6 joined
MasterDuke it does. reverse-continue again and it goes from 0x5 to 0x0 08:04
missing an MVM_ASSIGN_REF somewhere? 08:05
nine That or an MVMROOT 08:06
MasterDuke this looks like it was never set correctly and just gets randomly overwritten a couple times 08:07
and then eventually causes problems because of an `if (spesh_cand->body.jitcode) { ... }` 08:08
i'm guessing the problem is that i haven't correctly and/or fully adapted for the invoke->dispatch change 08:10
since this was pretty heavily tested before and made it through all builds, spectests, etc 08:11
nine With the latest rakudo commits, both rakudo's and Inline::Perl5's make test passes :) 08:41
And thanks to new-disp's architecture, supporting explicitly managed strings and Proxies does not cost any measurable performance :) 08:44
MasterDuke very cool
nine Next step will probably be to move unboxing from the VM to the dispatch program 09:03
The above commit was already a first step into that direction. Up to that NativeCall only allowed for boxed values and insisted on unboxing in the VM. Except for the JITed native calls which required unboxed values (accounting for much of the code in the generated function bodies. 09:05
09:29 SmokeMachine left 09:33 SmokeMachine joined 10:33 bloatable6 left, benchable6 left, releasable6 left, reportable6 left, quotable6 left, unicodable6 left, notable6 left, squashable6 left, bisectable6 left, committable6 left, evalable6 left, statisfiable6 left, linkable6 left, tellable6 left, greppable6 left, sourceable6 left, shareable6 left, nativecallable6 left, committable6 joined, notable6 joined, sourceable6 joined, unicodable6 joined, reportable6 joined 10:35 shareable6 joined, squashable6 joined, bisectable6 joined 10:36 statisfiable6 joined
nine I fear, this requires dispatch program ops that don't exist yet. 10:51
10:53 coverable6 joined 10:54 ggoebel joined
nine I thought that for unboxing I could just grab an Int's $!value attribute. But that is a bigint which we can't use directly as a native value. 10:55
Nicholas nine: ASAN is bored by your fixes. 11:09
nine Nothing like a boring Sunday :) 11:10
11:34 greppable6 joined 11:35 benchable6 joined 12:02 reportable6 left 12:05 reportable6 joined 12:35 bloatable6 joined, linkable6 joined 12:36 releasable6 joined 13:30 patrickb left 13:33 evalable6 joined 13:34 tellable6 joined
jnthnwrthngtn nine: I think we'll probably want to introduce dispatcher-track-unbox-[int|num|str], which will usually do the same as dispatcher-track-attr on objects, but can also result in different dispatch ops (and imply type/concreteness guards like attribute tracking does) 14:02
Also: yay, it's a further nice win that if one is dealing in native types, we can now easily end up with them never having to get boxed during the native calling process :) 14:03
nine jnthnwrthngtn: ah, thanks! Good to know that I'm on the right track. Will work on those dispatcher-track-unbox-[int|num|str] syscalls then 14:08
jnthnwrthngtn nine++ 14:26
jnthnwrthngtn is away for most of the rest of the day
jnthnwrthngtn is away for most of the rest of the day 14:27
14:34 nativecallable6 joined 14:43 squashable6 left 14:57 squashable6 joined 15:35 quotable6 joined 16:07 patrickb joined
nine Woohoo...dispatcher-track-unbox-int is working on P6opaque :) NativeRef apparently needs different handling, but it's a huge step forward 16:53
lizmat nine++ 16:56
17:19 linkable6 left, evalable6 left 18:03 reportable6 left 18:05 reportable6 joined 18:22 evalable6 joined 18:47 ggoebel left 18:51 ggoebel joined 18:59 ggoebel left 19:22 linkable6 joined
nine Well for one we simply must not unbox rw args. But there seem to be other cases where IntLexRef appears 20:24
20:26 patrickb left
timo yeah it comes up whenever the caller can't know if the target takes rw or not and you have a native int locally 20:27
nine The dispatch program ought to know. But how can I check if I've got a NativeRef and how can I unbox it? I can check that in the VM but that just feels wrong 20:32
timo not sure how to properly check; you can do a reprid comparison. it should also iscontrw or whatever we have for that, and something something primsec 20:39
japhb .ask samcv_ or anyone who knows Unicode well: If I concatenate two strings $a = ($b ~ $c), I know MoarVM will apply renormalization around the join point, but 1) Can this cause a change in any character left of the join point *other* than the very last character? 2) Is there a fast way to definitively tell by looking at $c whether renormalization will cross the boundary? 3) Are there any combining 23:46
tellable6 japhb, I'll pass your message to samcv
japhb characters that won't combine under NFG?
jnthnwrthngtn At the time I first did NFG I'm pretty sure the answer to 1 had to be "no" because "boundary or not" was a property of two consecutive codepoints. However, I think a later version of Unicode made it more complicated than that (but samcv++ implemented that, not me, and I forget the details). 23:51
That said, I'm not sure it made looking at the last grapheme insufficient 23:53
github.com/MoarVM/MoarVM/blob/d11b...nfg.c#L398 is where we try to avoid a full renormalization 23:55
I think the complexity involved here means the answer to 2 is "no" :) 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!