github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
nwc10 good *, #moarvm 05:42
06:31 domidumont joined
japhb good *, nwc10 06:42
nine good *! 06:44
07:04 zakharyas joined 07:05 Kaiepi left, Kaiepi joined
timotimo MasterDuke: very nice work! 08:15
MasterDuke timotimo: i still don't have it tracking memory without that instrumentation failure though 08:16
timotimo MasterDuke: have you tried outputting the pointer it complains about? perhaps it's about us using null pointers or something 08:19
MasterDuke which happens even if i run just `raku --full-cleanup -e ''`
not yet, i'll have to edit the tracy source to do that i believe 08:20
timotimo 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
MasterDuke true 08:26
0x7f9c1c001a90 (that's all the info you need, right?) 08:30
hm. i just added `fprintf(stderr, "%p\n", ptr);` to MVM_malloc, lots of the printed addresses are duplicated multiple times 08:32
btw, updated gist.github.com/MasterDuke17/7ddaf...ecc55a4a37 with the changes i've made to alloc.h 08:35
oh, but outputting them doesn't really help, because the profiled application doesn't crash, the collector just complains and stops collecting 08:38
timotimo which of the functions is the one that asplodes?
ah, crap, that does make it more difficult
OTOH, you can probably find the line where it complains and breakpoint that in gdb
MasterDuke yeah, also, turns out it was just added github.com/wolfpld/tracy/commit/8d...3d23a0e817 08:39
but that'll be for later, afk for a while &
timotimo do we ever by accident use free without MVM_ i wonder 08:42
nwc10 I thought I'd found them all (the free without MVM_)
timotimo alternatively, does tracy perhaps already implement a malloc, free, realloc symbol that does the tracking? quite possibly not, but who knows
MasterDuke src/moar.c:63 and src/profiler/telemeh.c:264
MasterDuke is now afk for real 08:43
timotimo ok at least that one in moar.c is paired with a bare malloc 08:55
08:58 frost-lab joined
timotimo 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
no that's the other way around 09:48
nwc10 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? 09:49
timotimo i think it probably doesn't intercept the allocation functions 10:04
tracy is a pretty cool tracing thingie with many features and a very nice graphical front-end 10:05
lizmat github.com/MoarVM/libatomic_ops/pull/1 11:12
lizmat can't merge that for some reason
11:22 zakharyas left
timotimo cdn.discordapp.com/attachments/557...e_view.gif - FSA's memory map live view in tracy while core setting compilation is going on 11:51
samcv 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:15
nine timotimo: holy fragmentation 12:36
jnthn Is that showing only allocations per the FSA or all allocations of the process? 12:50
12:51 zakharyas joined 12:56 dogbert17 joined 12:59 dogbert11 left 13:51 Geth joined 13:52 Geth left 14:00 Geth joined, Geth left 14:07 Geth joined 14:22 Geth left 14:24 Geth joined 14:25 Geth left, 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, Geth left 14:41 Geth joined
MasterDuke timotimo: cool. did you fix the problem i was seeing? 15:07
timotimo: do you see any difference if you increase github.com/MoarVM/MoarVM/blob/mast...lloc.h#L92 to something like 1024? 15:09
ooo, gcc 11 was just released, hope arch picks it up soon 15:22
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
Geth MoarVM/submodule-default-shallow-clone-5: d00746e0d4 | (Nicholas Clark)++ | tools/update-submodules.pl
tools/update-submodules.pl now defaults to --depth 5 instead of --depth 1

This leaves the last few commits of each submodule intact, which makes it easier to see what the last upstream commit was.		 19:00
19:22 vrurg joined 19:45 MasterDuke left, MasterDuke joined
samcv 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. 19:52
20:03 zakharyas joined 20:15 MasterDuke left
japhb 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:21
20:22 Geth left
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:22
20:43 patrickb left
samcv 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:50
20:53 zakharyas left
timotimo nine: that only shows the fsa, not regular mallocs and frees, though 20:57
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
japhb samcv: OK, that's what I thought, thanks for the confirmation. 21:11
timotimo very sad that the C api for tracy doesn't support recording lock activity 21:18
21:32 MasterDuke joined
MasterDuke timotimo: found anything new with it yet? 21:33
timotimo not at all :) 21:36
i put a zone in for the spesh worker starting and stopping, which is cute
MasterDuke 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
timotimo frames doesn't make sense for moarvm itself, yeah
maybe for a raku program though
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:38
did you have anything in there to set thread names? 21:39
MasterDuke not yet 21:40
timotimo it looked like you did from your screenshot
MasterDuke it picked that up automatically
21:41 Geth joined, Geth left 21:42 Geth joined
timotimo i ran my rakudo with sudo but didn't get any of that :( 21:42
or maybe i'm misunderstanding
MasterDuke huh
i just ran stuff like `TRACY_NO_EXIT=1 sudo ./install/bin/nqp-m --full-cleanup -e ''` 21:43
timotimo cdn.discordapp.com/attachments/557...nknown.png funny to see the spesh worker thread migrate between cores 21:44
oh i do see the spesh optimizer thread's name! 21:45
21:48 linkable6 left
MasterDuke github.com/MasterDuke17/MoarVM/tre...cy_support 21:55
guess i might as well PR it to get comments/suggestions 22:00
why isn't sticking the #include in moar.h sufficient? 22:02
Geth MoarVM: MasterDuke17++ created pull request #1482:
Add tracy as a submodule and build option		 22:34

Powered by Cro and the Raku® Programming Language.

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

Thank you!