| 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 | |||
