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:07 reportable6 left
japhb MasterDuke: Let me see if I understand. Are you saying that the fastest combo so far is just using mimalloc, with literally everything else the same? Or does this also include turning off FSA as well? 00:09
00:10 reportable6 joined
japhb is somewhat boggled that several decades in, the CS community is *still* learning significantly more about memory allocation. 00:10
moon-child really? 00:17
I mean, c4 was around 2010
and, hm, jemalloc was 2006 apparently; I thought it was more recent. Still 00:19
japhb moon-child: And before that was Bohm, and ... 00:28
moon-child bdw has oooold roots, though 00:30
80s I think
but yeah it is high quality. At one point its heap was better than that of contemporary malloc implementations, so using it gave better performance 00:31
01:06 discord-raku-bot left 01:07 discord-raku-bot joined 03:54 committable6 left, quotable6 left, releasable6 left, tellable6 left, reportable6 left, sourceable6 left, evalable6 left, nativecallable6 left, squashable6 left, shareable6 left, linkable6 left, bloatable6 left, vrurg_ left, greppable6 left, coverable6 left, notable6 left, benchable6 left, statisfiable6 left, unicodable6 left, bisectable6 left, vrurg joined 03:55 evalable6 joined, sourceable6 joined 03:56 squashable6 joined, committable6 joined, statisfiable6 joined, shareable6 joined, notable6 joined, nativecallable6 joined, linkable6 joined 03:57 releasable6 joined, coverable6 joined, bloatable6 joined 04:55 reportable6 joined, greppable6 joined 04:56 benchable6 joined 04:57 tellable6 joined, quotable6 joined 05:55 unicodable6 joined 05:56 bisectable6 joined 06:07 reportable6 left
MasterDuke japhb: correct, stock+mimalloc was fastest, and i have not yet tried mimalloc+turning off FSA 07:55
09:09 linkable6 left, reportable6 joined
nine Aaah...finally! I've got the Proxy stuff working (and thus that failing test in LibXML fixed). I was just missing a guard on the callee and got (yet again) confused by missing debug output because I (yet again) forgot that dispatch programs will only run once. 10:34
timo you can make dispatch programs run every time if you liek? :D 10:40
11:06 squashable6 left
nine Geth down? 11:21
Ah, no
11:48 frost joined
lizmat ah? 11:54
Geth: help 11:55
Geth lizmat, Source at github.com/Raku/geth To add repo, add an 'application/json' webhook on GitHub pointing it to webhooks.liz.nl/?chan=%23raku and choose 'Send me everything' for events to send | use `ver URL to commit` to fetch version bump changes
lizmat indeed looks up to me :-)
nine I was just looking for the message in the wrong channel
lizmat ah, *phew* 11:58
nine The t/04-nativecall/21-callback-other-thread.t segfault is quite surprising in that it appears to be a bug in MVM_args_set_dispatch_result_int. This function is passed an MVMFrame *target and will write the result into target->return_value->o (if an object is requested). 11:59
When boxing the return value, GC may be triggered and can move the frame, thus we dereference a bogus return_value pointer and segfault. 12:00
What's so surprising is that this is a very central function that's called all over the place.
Though I guess the combination of required factors may be somewhat rare. We need tc->cur_frame to be a heap frame, the frame returning a native integer (e.g. return_i) and the caller expecting an object. And of course an untimely GC run. 12:02
12:08 reportable6 left 12:10 reportable6 joined
dogbert17 nine++, looks like you had no problem reproing that one :) 12:10
nine No, and I'm glad about that :) 12:11
dogbert17 I ran the entire (almost) spectest suite with MVM_GC_DEBUG=3 a few days ago and that was the only thing that cropped up 12:13
Geth MoarVM/fix_autoboxing_gc_issue: cb27ba7f3d | (Stefan Seifert)++ | src/core/args.c
Fix possible access to fromspace when autoboxing return values

If the target frame (e.g. tc->cur_frame) is a heap frame that lives in the nursery, the return value is a native value (e.g. return_i or a native call), the caller expects an object and boxing happens to trigger a GC run, the target frame could be moved before we dereference the target pointer to get the return_value register. This would lead to a segfault with GC_DEBUG 3. ... (5 more lines)
12:19
nine Luckily this fix ^^^ should be performance neutral.
dogbert17: wow, how long did that take?
dogbert17 Files=1349, Tests=117784, 17443 wallclock secs (40.33 usr 5.54 sys + 96045.85 cusr 12919.49 csys = 109011.21 CPU) 12:23
Result: FAIL
nine That's not that bad actually 12:30
13:33 frost left 13:39 squashable6 joined 13:52 discord-raku-bot left, discord-raku-bot joined
Geth MoarVM/fix_segfault_with_void_native_calls: 768228b327 | (Stefan Seifert)++ | 2 files
Fix return register staying uninitialized on dispatch to void native functions

This got lost when turning nativecall_invoke into nativecall_dispatch. Even if the native function itself doesn't return a result (i.e. void), we have to set the call's result to something as in general the call will be initiated through dispatch_o which is expected to return an object. NativeCall convention is to return a type object in this case. So follow the convention
15:44
MoarVM/fix_segfault_with_void_native_calls: fd6a41035e | (Stefan Seifert)++ | src/spesh/disp.c
Fix uninitialized return register on translated calls to void native functions

We optimize calls to native functions without return values (i.e. void) to sp_runnativecall_v. Nevertheless we have to initialize the original target register with something (i.e. the return value type object), because the register may be read after a deopt. This is all the more likely as a guard on the return register would trigger a deopt if the register contains a NULL value.
Fixes segfaults after deopts after void native calls.
dogbert17 nine: looks like you're on a rampage 15:45
Geth MoarVM: niner++ created pull request #1622:
Fix segfault with void native calls
15:48
nine Yeah, but that's definitely enough work for this weekend
dogbert17 time for a well deserved rest
MasterDuke so far, mimalloc with FSA_DEBUG lightly modified to just directly call the regular alloc functions isn't that slow. wonder how it'll end up comparing to master with the same modifications to FSA_DEBUG 15:52
in fact, it builds rakudo faster than stock for me by 1-2s 15:53
16:12 linkable6 joined 18:07 reportable6 left 19:07 reportable6 joined
MasterDuke timo: you might find github.com/MoarVM/MoarVM/issues/1623 interesting 22:29
23:46 committable6 left, reportable6 left, quotable6 left, benchable6 left, greppable6 left, linkable6 left, evalable6 left, tellable6 left, nativecallable6 left, bloatable6 left, notable6 left, unicodable6 left, releasable6 left, sourceable6 left, bisectable6 left, shareable6 left, coverable6 left, squashable6 left, statisfiable6 left 23:47 unicodable6 joined, reportable6 joined, quotable6 joined 23:48 evalable6 joined, sourceable6 joined, nativecallable6 joined, notable6 joined 23:49 squashable6 joined