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:03 linkable6 left, evalable6 left 00:06 evalable6 joined 00:07 reportable6 left 00:36 Kaiepi left 00:39 Kaiepi joined 00:54 Kaiepi left 01:03 Kaiepi joined 01:10 reportable6 joined 01:16 Kaiepi left 01:43 Kaiepi joined 01:46 Kaiepi left 01:49 discord-raku-bot left, discord-raku-bot joined 01:51 Kaiepi joined 01:53 gfldex left 01:57 gfldex joined 01:58 Kaiepi left 02:00 Kaiepi joined 03:01 nine left, nine joined 03:05 frost joined 04:21 frost left 04:46 kjp left 04:50 kjp joined 05:23 frost joined 06:02 kjp left 06:07 reportable6 left 06:10 reportable6 joined 06:14 kjp joined 06:37 frost left 06:40 frost joined 07:04 linkable6 joined 07:16 frost left
Nicholas good *, * 07:18
07:28 frost joined 07:34 frost left
Geth__ MoarVM: nwc10++ created pull request #1649:
Convert free_at_safepoint from a vector to a linked list and eliminate its associated mutex		 08:20
Nicholas oh, seems that clang hates me 08:24
OK, why is *my* (er, "my") clang 11 different from Azure's clang 11? 08:40
"check your staging" - er, I mean, "check your checkout" - wrong branch 09:28
12:07 reportable6 left 12:08 reportable6 joined 12:41 kjp left 12:45 bartolin_ joined, jnthn joined 12:46 bartolin left, ugexe left, discord-raku-bot left, jnthnwrthngtn left, leedo left, discord-raku-bot joined, ugexe joined 12:47 leedo joined
nine The Kerbal is strong in you 12:53
12:54 kjp joined 13:10 Kaiepi left, Kaiepi joined 14:30 Geth__ left, Geth joined 14:50 Geth left 14:51 Geth joined
jdv there are quite a few instances of "Unhandled exception: unreachable unbox 1" in the last blin run from y'day - can someone look into those? 16:17
16:31 evalable6 left, linkable6 left 18:07 reportable6 left 18:10 reportable6 joined 18:31 evalable6 joined 18:38 dogbert17 joined 18:40 dogbert11 left 18:55 Kaiepi left 18:56 Kaiepi joined
nine MasterDuke: github.com/Garland-g/NativeHelpers-iovec seems to suffer from some mimalloc regression. I get very random failures and segfaults. With --no-mimalloc I at least get consistent test failures 19:14
19:15 Geth left, Geth joined
jnthn nine: Looks like it's calling the standard malloc/free, so if it ever hits upon something VM-allocated there'll be bother 19:28
tellable6 2021-07-02T14:05:35Z #moarvm <patrickb> jnthn: The runner generated in the build dir uses execve, while the installed one doesn't. You could just debug the installed executable
2021-10-15T15:42:15Z #raku-dev <tbrowder> jnthn roast PR #759 for the heredoc change is ready for review again
nine jnthn: which means that we're using mimalloc where we should use standard malloc 19:35
Like: body->cstruct = MVM_calloc(1, repr_data->struct_size > 0 ? repr_data->struct_size : 1); 19:38
I thought I pointed out this exact issue?
20:00 kjp left 20:01 kjp joined
MasterDuke you mean that should be calloc instead of MVM_calloc? 20:03
nine Yes, as ownership may get passed to some native library which will expect to be able to free() it
MasterDuke github.com/MoarVM/MoarVM/blame/mas...uct.c#L424 is 7 years old 20:04
nine And for those 7 years MVM_calloc was just calloc
MasterDuke so all/some of the MVM_* alloc-related functions in nativecall should be just the libc functions? 20:05
nine valgrind is decidedly unhappy with NativeHelpers-iovec even with --no-malloc, so the module may just be buggy
MasterDuke: yes
MasterDuke fwiw, i don't remember any comment about this before, but maybe i just missed it
nine github.com/MoarVM/MoarVM/pull/1634...1007724975 20:07
MasterDuke hm, should those be `#ifdef  MVM_USE_MIMALLOC`? or just straight libc calls in case we ever want to use something else in the MVM_* functions
nine I'd say straight libc calls
Which in case of NativeHelpers-iovec doesn't seem to change anything, but will be goot practice anyway 20:08
MasterDuke ah, guess i didn't realize the implications of that comment 20:09
i'm not 100% sure i'll know what/where to change. stuff in src/core/nativecall* + src/6model/reprs/C* ? 20:10
i assume repr_data can stay MVM_*? 20:17
what about child_objs? 20:19
nine Things like CStruct's cstruct or CArray's storage or encoded strings, i.e. pointers we pass to C code 20:24
MasterDuke wait, you're saying CArray's storage should stay MVM_*? or should be changed? 20:29
ugh, right, recalloc isn't a standard function... 20:31
luckily it's not too terribly complicated... 20:32
21:26 ilogger2 left
jnthn Yeah, fully agree the native data structures really should use the standard C library ones 22:16
22:20 ilogger2 joined
MasterDuke i think i have about a 95% patch at this point. i just realized i do want to go back and add some `#ifdef MVM_USE_MIMALLOC` though, because in the not-mimalloc case we can avoid some copying 22:23
e.g., there are a couples places that call MVM_string_utf8_encode_C_string where i'm now then also mallocing some memory and strcpying the result into the new memory then MVM_freeing the old. in the non-mimalloc case that isn't necessary 22:25
moon-child why not pass in an allocator function pointer? 22:29
22:32 linkable6 joined
MasterDuke seems like overhead that isn't usually necessary. only the nativecall code has this issue, all other uses of MVM_string_utf8_encode_C_string are fine 22:33
moon-child eh, it'd branch-predict well. So no overhead if it's in a hot path 22:35
Geth MoarVM: MasterDuke17++ created pull request #1650:
Use libc allocator functions for NativeCall		 23:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!