[02:06] *** Kaiepi joined [02:09] *** frost-lab joined [02:49] *** sivoais left [02:50] *** sivoais joined [02:56] *** frost-lab left [03:00] *** frost-lab joined [05:09] *** frost-lab left [05:42] good *, #moarvm [06:31] *** domidumont joined [06:42] good *, nwc10 [06:44] good *! [07:04] *** zakharyas joined [07:05] *** Kaiepi left [07:05] *** Kaiepi joined [08:15] MasterDuke: very nice work! [08:16] timotimo: i still don't have it tracking memory without that instrumentation failure though [08:19] MasterDuke: have you tried outputting the pointer it complains about? perhaps it's about us using null pointers or something [08:19] which happens even if i run just `raku --full-cleanup -e ''` [08:20] not yet, i'll have to edit the tracy source to do that i believe [08:25] i think it'll b eenough to just output for all addresses in our *allocs and just look at the very last one [08:25] and i'd recommend running nqp instead of raku since it's so much smaller, and perhaps also disabling spesh [08:26] true [08:30] 0x7f9c1c001a90 (that's all the info you need, right?) [08:32] hm. i just added `fprintf(stderr, "%p\n", ptr);` to MVM_malloc, lots of the printed addresses are duplicated multiple times [08:35] btw, updated https://gist.github.com/MasterDuke17/7ddafa9a98898c57b4a63cecc55a4a37 with the changes i've made to alloc.h [08:38] oh, but outputting them doesn't really help, because the profiled application doesn't crash, the collector just complains and stops collecting [08:38] which of the functions is the one that asplodes? [08:38] ah, crap, that does make it more difficult [08:38] OTOH, you can probably find the line where it complains and breakpoint that in gdb [08:39] yeah, also, turns out it was just added https://github.com/wolfpld/tracy/commit/8dd92f32af91e9a8243f80c9c67a343d23a0e817 [08:39] but that'll be for later, afk for a while & [08:42] do we ever by accident use free without MVM_ i wonder [08:42] I thought I'd found them all (the free without MVM_) [08:42] alternatively, does tracy perhaps already implement a malloc, free, realloc symbol that does the tracking? quite possibly not, but who knows [08:42] src/moar.c:63 and src/profiler/telemeh.c:264 [08:43] * MasterDuke is now afk for real [08:55] ok at least that one in moar.c is paired with a bare malloc [08:58] *** frost-lab joined [09:47] ah, it could very well be that we take something allocated by an outside library and free it somewhere in moar [09:47] that could upset tracy [09:48] no that's the other way around [09:49] OK, I'm going to be naive here - what is tracy, and if it's intercepting malloc/realloc/free, how come it can't do it with dlopen hackery? [10:04] i think it probably doesn't intercept the allocation functions [10:05] tracy is a pretty cool tracing thingie with many features and a very nice graphical front-end [11:12] https://github.com/MoarVM/libatomic_ops/pull/1 [11:12] * lizmat can't merge that for some reason [11:22] *** zakharyas left [11:51] https://cdn.discordapp.com/attachments/557618333755768832/836570197338751006/fixedsize_allocator_live_view.gif - FSA's memory map live view in tracy while core setting compilation is going on [12:15] i was reading some stuff about C and locales. and it made me think about how MoarVM handeled locales. Such as if any of the libc or other library functions we use change functionality based on locale. I am guessing we probably would have found this out by now. But wanted to ask :) [12:36] timotimo: holy fragmentation [12:50] Is that showing only allocations per the FSA or all allocations of the process? [12:51] *** zakharyas joined [12:56] *** dogbert17 joined [12:59] *** dogbert11 left [13:51] *** Geth joined [13:52] *** Geth left [14:00] *** Geth joined [14:00] *** Geth left [14:07] *** Geth joined [14:22] *** Geth left [14:24] *** Geth joined [14:25] *** Geth left [14:25] *** Geth joined [14:27] *** frost-lab left [14:29] *** Geth left [14:30] *** Geth joined [14:33] *** Geth left [14:35] *** Geth joined [14:38] *** Geth left [14:40] *** Geth joined [14:40] *** Geth left [14:41] *** Geth joined [15:07] timotimo: cool. did you fix the problem i was seeing? [15:09] timotimo: do you see any difference if you increase https://github.com/MoarVM/MoarVM/blob/master/src/core/fixedsizealloc.h#L92 to something like 1024? [15:22] ooo, gcc 11 was just released, hope arch picks it up soon [15:24] *** domidumont left [16:49] *** domidumont joined [17:08] *** vrurg left [17:26] *** MasterDuke left [17:39] *** domidumont left [18:09] *** zakharyas left [18:46] *** MasterDuke joined [18:48] *** patrickb joined [19:00] ¦ MoarVM/submodule-default-shallow-clone-5: d00746e0d4 | (Nicholas Clark)++ | tools/update-submodules.pl [19:00] ¦ MoarVM/submodule-default-shallow-clone-5: tools/update-submodules.pl now defaults to --depth 5 instead of --depth 1 [19:00] ¦ MoarVM/submodule-default-shallow-clone-5: [19:00] ¦ MoarVM/submodule-default-shallow-clone-5: This leaves the last few commits of each submodule intact, which makes it [19:00] ¦ MoarVM/submodule-default-shallow-clone-5: easier to see what the last upstream commit was. [19:00] ¦ MoarVM/submodule-default-shallow-clone-5: review: https://github.com/MoarVM/MoarVM/commit/d00746e0d4 [19:22] *** vrurg joined [19:45] *** MasterDuke left [19:45] *** MasterDuke joined [19:52] looking into it, it looks like we shouldn't have any problems of locale affecting MoarVM's parsing of numbers for instance, unless something nativecall potentially called `setlocale`. Though I haven't tested this. [20:03] *** zakharyas joined [20:15] *** MasterDuke left [20:21] samcv: We'd still have the problem that locale is process-wide, yes? So something like a Cro app trying to serve localized pages to each user and depending on the libc concept of locale would find the various site users stomping on each other? [20:22] *** Geth left [20:22] * japhb is under the assumption that he's going to have to just recreate locales from scratch (possibly using the CLDR modules) so as to be able to have them different per-user. [20:43] *** patrickb left [20:50] japhb, well as long as you don't try and use the C-library locale then you should be fine. And MoarVM doesn't use it. And Cro shouldn't either unless it uses NativeCall that way. which it hopefully won't. but if it did then it'd apply process wide and break things, probably number parsing, maybe some sprintf's [20:53] *** zakharyas left [20:57] nine: that only shows the fsa, not regular mallocs and frees, though [20:58] jnthn: your assumption was right re: fsa only [20:58] i didn't try to put the macros on malloc and free since that gave masterduke some trouble [21:11] samcv: OK, that's what I thought, thanks for the confirmation. [21:18] very sad that the C api for tracy doesn't support recording lock activity [21:32] *** MasterDuke joined [21:33] timotimo: found anything new with it yet? [21:36] not at all :) [21:36] i put a zone in for the spesh worker starting and stopping, which is cute [21:37] i haven't quite figured out zones and frames and such. i sort of assume most of our stuff wouldn't ever have frames [21:37] frames doesn't make sense for moarvm itself, yeah [21:37] maybe for a raku program though [21:38] the tools tracy has for "frames" are tuned pretty much for video games and anything that wants to hit a framerate target as closely as possible [21:39] did you have anything in there to set thread names? [21:40] not yet [21:40] it looked like you did from your screenshot [21:40] it picked that up automatically [21:41] *** Geth joined [21:41] *** Geth left [21:42] *** Geth joined [21:42] i ran my rakudo with sudo but didn't get any of that :( [21:42] or maybe i'm misunderstanding [21:42] huh [21:43] i just ran stuff like `TRACY_NO_EXIT=1 sudo ./install/bin/nqp-m --full-cleanup -e ''` [21:44] https://cdn.discordapp.com/attachments/557618333755768832/836719375154151424/unknown.png funny to see the spesh worker thread migrate between cores [21:45] oh i do see the spesh optimizer thread's name! [21:48] *** linkable6 left [21:55] https://github.com/MasterDuke17/MoarVM/tree/add_minimal_tracy_support [22:00] guess i might as well PR it to get comments/suggestions [22:02] why isn't sticking the #include in moar.h sufficient? [22:34] ¦ MoarVM: MasterDuke17++ created pull request #1482: Add tracy as a submodule and build option [22:34] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1482