dalek arVM: e688260 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
add instrumentation values to MVMStaticFrame's unmanaged size.
00:07
arVM: 4812655 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
account for unmanaged_size of spesh candidates and jitcode.
timotimo so much typing
but at least don't requires the brane
00:17 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'account for unmanaged_size of spesh candidates and jitcode.' 00:17
travis-ci.org/MoarVM/MoarVM/builds/118890447 github.com/MoarVM/MoarVM/compare/5...1265520bd8
00:17 travis-ci left
timotimo oh well 00:19
00:20 vendethiel joined
dalek arVM: 2e303cf | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
fix the typos
00:20
00:32 travis-ci joined
travis-ci MoarVM build passed. Timo Paulssen 'fix the typos' 00:32
travis-ci.org/MoarVM/MoarVM/builds/118891517 github.com/MoarVM/MoarVM/compare/4...303cf17554
00:32 travis-ci left
timotimo i feel like merging the annotate_refs_reprapi branch into maste 00:46
master
sometimes the ABC object is kept alive by a method cache of some random object %) 00:53
quite likely somewhere in the compiler, i'd suggest 00:55
but QAST::Var (STable) (44777)
--[ Method cache ]-->
isn't so terribly insightful, i dare say
good news! when i run the eval 30 times, i only find like 27 ABCs! 01:02
so at some point it'll probably just stop leaking :D 01:03
because at some point all caches and such will be filled and nothing more will get in :D 01:04
out of 90 goes through the for loop for evaling, 74 ABC stables stay around :\ 01:10
571 megabytes of heap dump data ... no big deal :P 01:13
01:14 vendethiel joined
timotimo OK, with 200 runs through the eval, only 108 STables with type="ABC" stick around 01:20
t.h8.lv/all_paths_here.png ; with the patch i have, it doesn't seem like the int cache is eliminated "enough" 01:42
jnthn: you may find this interesting; i'm not going to throw away the raw data, i'll also upload the .dot file 01:46
t.h8.lv/all_paths_here.dot
t.h8.lv/all_paths.txt - this is the raw output from our heap analyzer, btw, it has the edge infos, too.
01:48 ilbot3 joined
timotimo er, not 74 01:49
05:52 TimToady joined 06:48 domidumont joined 06:53 domidumont joined
timotimo also includes the actual root that caused something to be included 07:48
and next step would be to also include the descriptions of the paths, but that could bloat up the image quite a bit. i have an idea for that, though. almost a clever one :) 07:49
08:12 sivoais joined
timotimo the files are already updated at their original URL, yay 08:15
and the script i've been making for this is in my fork of the heapanalyzer 08:16
10:58 FROGGS joined 11:17 vendethiel joined
timotimo burgh. i'm trying to work on cross-inline optimizations and my changes actually cause an inline that used to succeed to fail now >:( 11:54
11:55 vendethiel joined
timotimo in another place it causes a fastinvoke to turn into an invoke 12:02
i don't even :|
12:11 stmuk_ joined
diakopter lolz 12:27
stmuk_ github.com/MoarVM/MoarVM/pull/350 13:07
13:07 Ven joined
jnthn Can merge after travis :) 13:08
I'm a tad curious what $OS_FREEBSD{cc} is 13:09
And if that's a hardcoded value
stmuk_ its the result of cc => (qx!cc -v 2>&1 >$devnull! !~ 'clang') ? 'gcc' : 'clang',$ 13:11
probably the data structure should define cc in one place only 13:12
timotimo perhaps we should instead have two entries for freebsd; one with gcc and one with clang?
the interpolated value there sticks out like a sore thumb :)
stmuk_ well really I think all systems should detect gcc or clang rather than hardcode 13:13
I'd also assume quite a few people use gcc on solaris as well
timotimo mhm mhm
jnthn stmuk_: Fair enough, thanks 13:14
dalek arVM: eba9b0f | (Steve Mynott)++ | build/setup.pm:
fix compile on FreeBSD 9
13:19
arVM: bccdea1 | jnthn++ | build/setup.pm:
Merge pull request #350 from stmuk/master

fix compile on FreeBSD 8 and 9 (also tested not to break 10)
timotimo jnthn: +1/-1 on merging the "explain references" branch? 13:21
jnthn timotimo: Need to review it yet
timotimo gotcha 13:23
jnthn (Will be about top of my todo list when I have tuits though, because I want to use the functionality it adds :)) 13:26
13:42 zakharyas joined
diakopter yo yo 14:04
timotimo yo diakopter
how do yo do?
how yo yo yo?
diakopter more info on my config problem
timotimo yow yo yo yo?
diakopter add_entry(tc, config, "libdir", "C:\\Users\\mwilson\\src\\v\rakudo\\install\\bin");
from config.c
see any problem? :lolcry: 14:05
timotimo \r, yeah
diakopter I haven't exhaustively looked, but I hadn't found its origin yet 14:06
I was hoping someone else would know more offhand
timotimo no clue; all i know is something in Configure.pl must generate that file 14:07
which i bet you already knew
diakopter well I traced it back to moar's config
so it's not in rakudo/nqp
timotimo rakudon't 14:08
diakopter jnthn: any ideas? 14:21
jnthn diakopter: Not really...I'd look at the code that fills out config.c.in 14:34
grep for that I guess
diakopter oki 14:35
well, this is part of the cause, here's what nqp sent moar config: 14:38
CONFIG = --optimize --prefix=C:\Users\mwilson\src\v/rakudo\install --make-install 14:39
(obviously it should handle that correctly too, though) 14:40
timotimo i wonder what other cases we have where we hold on to lots and lots and lots of stuff that we don't need any more at all 15:09
granted, the SC case is a bit more extreme than others would be 15:10
but we'll be running around with fully populated method caches and specialization for the whole compiler after going into the user code, for example
jnthn SCs are used to resolve all wval instructions, of which there are plenty 15:11
timotimo but i suppose the only part where that's really bothersome so far is those top 2 methods of the mast compiler?
jnthn As for the compiler...true, but you might EVAL, interpolate regex, etc. 15:13
timotimo ah, regex interpolation is a case i hadn't considered
15:40 Ven joined 15:55 cognominal joined
timotimo i just ran perf record on the heapanalyzer (up until i got a snapshot's summary) 16:07
looks like it spends a significant amount of time in the fixedsizealloc
by which i mean like 30%
timotimo tries without jit to get more info, hopefully 16:08
jnthn Most multi-threaded things bottleneck on FSA at the moment... 16:11
(For frame allocations) 16:12
timotimo oh, OK 16:22
parse-static-frames gets quite a few things inlined, but it doesn't seem like the .Int method calls get fully inlined. instead, they turn into a thing that takes the dispatcher and invokes something that gets taken from a spesh slot 16:37
and those still contain hllize calls for some reason
ah, probably just the missing discovery step after inlining, so the known type doesn't make it 16:38
and thus no hll_owner
i hate it when spesh logs sufficiently diverge to not become easily diffable >_> 17:47
ah, one of the two pieces of output has disappeared 18:03
you poke spesh and *something* happens. but what? nobody knows 18:06
18:09 Ven joined
timotimo i think i'll probably be stitching the inlined blocks into the dominance tree. because otherwise the spesh won't touch these newly added blocks 19:17
since it only goes by children, not by linear_next