01:06 colomon joined 02:22 colomon joined 07:04 domidumont joined 07:09 domidumont joined 09:17 Ven joined 11:06 Ven joined 11:52 colomon joined 12:01 vendethiel joined 12:04 colomon joined 12:45 Ven joined 12:57 colomon joined 13:15 zakharyas joined 13:24 colomon joined 13:39 colomon joined 14:06 ZoffixWin joined
ZoffixWin Hey. Someone told me I need some sort of flag to enable before attempting to use valgrind, because I'd get false positives otherwise.... what's that flag and how do I set it? 14:07
timotimo you just have to run moar with --full-cleanup 14:08
ZoffixWin I actually see perl6-valgrind-m in rakudobrew bin 14:15
timotimo yeah
but it doesn't set --full-cleanup
because nobody put it in yet
*hint hint*
ZoffixWin But I've no idea how to put in --full-cleanup. All these scripts are some sort of a Perl 5 script :/ 14:16
nm 14:17
timotimo just cat it and run it by hand 14:18
ZoffixWin Adding --full-cleanup produces segmentation fault: gist.github.com/zoffixznet/c9951c3...2bef733f73 14:24
timotimo where is that segmentation fault? :o 14:26
aaw, you have your moar built without --debug 14:27
ZoffixWin Oh
timotimo turns out we destroy the nfg stuff after the fixed size allocator got destroyed 14:28
so when i move fsa_destroy after nfg_destroy, it should not give you any errors any more.
timotimo tries it out 14:29
great, it doesn't give any errors any more
ZoffixWin has no idea what any of that means... 14:30
dalek arVM: f98914f | timotimo++ | src/moar.c:
the NFG uses the FSA, so have to destroy FSA after NFG.
timotimo :)
just that the error was helpful and very simple
but also rather harmless 14:31
ZoffixWin So, do I still need to rebuild with --debug to get --full-cleanup to work?
Or is the fix you just pushed the fix for the segmentation fault?
timotimo no, but it'll give better tracebacks in valgrind
it fixes the errors you got, yeah 14:32
was it really a segmentation fault?
ZoffixWin I see 'Segmentation fault' on this line: gist.github.com/zoffixznet/c9951c3...e-bash-L20
timotimo oh! haha
that's just for saying the banner up top
that one didn't need --full-cleanup, but it's probably fixed now 14:33
thanks for the tip in any case :) 14:35
14:51 Ven joined
dalek arVM: be10119 | timotimo++ | src/moar.c:
close dynvar log filehandle in instance destroy
15:29
arVM: e240e75 | timotimo++ | src/moar.c:
cross thread write logging has a mutex. close it.
timotimo ^- not worth a lot, but cheap to do
the heap collection subsystem doesn't offer a way to destroy the data without creating the output yet; we might want to have a "cancel heap snapshot mode" function that just destroys the heap snapshot data that belongs to an instance 15:37
16:06 cognominal joined 17:44 cognominal joined
moritz www.reddit.com/r/ProgrammingLangua...le_target/ looks like it could do from some input from MoarVM deleopers :-) 19:04
erm, that no grammar 19:05
some input would be beneficial to that thread :-)
geekosaur s/do from/do with/ ? 19:07
timotimo well, we only use dynasm, which is a shared dependency between our stuff and luajit's stuff now 19:08
the luajit IR isn't really similar to what we target, i don't think
moritz oh 19:09
jnthn Also, luajit doesn't use dynasm for its JIT, afaik, just for its hand-coded interpreters.
(I think this is true of luajit 2, and luajit 1 did use dynasm for its JIT also) 19:10
timotimo oh, interesting 19:12
19:37 zakharyas joined
timotimo MadcapJake: do note, however, that the multi-core version spends about 50% total time contending for a lock on one of our allocators 21:56
MadcapJake could you elaborate a bit? Is this the $input-channel.list that you're speaking of? 21:58
timotimo no
just internal stuff. the thing in question here is the Fixed Size Allocator, which we currently use to allocate every single call frame 21:59
so basically, the threads are fighting to be allowed to invoke subs 22:00
if we could be invoking less stuff, i.E. have fewer curlies or somehow make the optimizers better able to inline stuff, it wouldn't be as bad
alternatively, we wait for jnthn's current refactoring work. on this particular code, the partial refactor still crashes.
MadcapJake interesting! Nice to hear the current refactor will address this. Though I'm not quite grasping how. 22:05
timotimo want me to explain what jnthn is up to? 22:14
his own blog posts can probably explain better than me, but i can answer questions 22:15
MadcapJake i've read them actually, but I've not quite comprehended them :) isn't the big idea that call frames will be gc-able and reference counting will go away? (probably way off on that :P) 22:21
timotimo right, but with the added thing that whenever we know for a fact that a bunch of frames will all be ref-counted-1, we can have them in a cheaper storage than GC-managed 22:28
and only when a frame escapes, it'll be migrated to GC storage
that'll also likely mean we'll be allocating things in a per-thread rather than shared pool 22:30
meaning all the contention in multi-threaded situations will also go away
MadcapJake wow nice! 22:31
22:49 diakopter joined
timotimo well, of course not all, as in all 22:53
but the big one will be gone. the one where every new call frame has to go through one central resource 22:54