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.
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
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
MasterDuke japhb: correct, stock+mimalloc was fastest, and i have not yet tried mimalloc+turning off FSA 07:55
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
nine Geth down? 11:21
Ah, no
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
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
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
MasterDuke timo: you might find github.com/MoarVM/MoarVM/issues/1623 interesting 22:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!