|
01:49
ilbot3 joined
03:21
geekosaur joined
03:37
vendethiel joined
05:48
domidumont joined
05:53
domidumont joined
06:34
zakharyas joined
08:11
leont joined
08:39
zakharyas joined
08:40
btyler joined
08:44
brrt joined
|
|||
| brrt | ohhai #moarvm | 08:58 | |
| jnthn | o/ brrt | 09:12 | |
| brrt | \o jnthn | 09:20 | |
| i'm kind of hoping i can get the register allocator finished within a shortish timeframe... and after that, i'd think the expr jit would become mergeable | 09:26 | ||
| or, otherwise asked, what more would be necessary / desirable to have prior to merging when that is done? | |||
| we'd like / want an optimizer, but that doesn't have to be present prior to merging, i'd think | 09:27 | ||
| jnthn | brrt: What will we have in terms of regressions upon a merge? | 09:28 | |
| brrt | breaking tests? well, currently, none, but currently, the expr jit is really weak | 09:29 | |
| with the register allocator, it will be considerably more useful, and then the answer is 'hopefully none' | 09:30 | ||
| we won't get any cases where we could compile something today that we won't be able with the expr jit merged, because of the piecemeal way the expr jit works | 09:31 | ||
| we'll spend more work on JIT compiling, obviously, but I have no idea whether that will be significant | |||
| as far as i can see, it's still a pretty cheap JIT | 09:32 | ||
| jnthn | Yeah...guess we can do a few small perf tests to make sure we don't get notably *worse* at some things. | 09:41 | |
| But if it's piecemeal introduction that seems less likely | |||
| I was mostly meaning breaking stuff though. | 09:42 | ||
| jnthn is free to do Perl 6 / MoarVM bits the rest of the day o/ | 10:13 | ||
| nwc10 | please remember to eat | 10:19 | |
| jnthn | :-) | 10:21 | |
| My wife is good at reminding me about that also :) | |||
| timotimo: Am reviewing/tidying/merging stuff from your describe refs branch | 10:25 | ||
| dalek | arVM: 7eb7835 | timotimo++ | src/6model/ (44 files): give all REPRs a "describe_refs" function |
10:29 | |
| arVM: 83a0ce6 | timotimo++ | src/profiler/heapsnapshot.c: actually call describe_refs for things |
|||
| arVM: 4df1fd9 | timotimo++ | src/6model/reprs/MVMHash.c: give MVMHash an unmanaged_size |
|||
| brrt | (lets try not to merge when it is still breaking :-)) | 10:40 | |
| i mean the expr jit, not timotiomo's work :-) | |||
| jnthn | :) | 10:51 | |
| dalek | arVM: 7d78b8d | jnthn++ | src/profiler/heapsnapshot.c: describe_refs is an alternative to gc_mark |
10:54 | |
|
11:42
brrt joined
|
|||
| dalek | arVM: 2c415d5 | jnthn++ | src/6model/reprs/Lexotic.c: Implement describe_refs for lexotic. |
12:27 | |
| arVM: 0b95607 | timotimo++ | src/6model/reprs/MVMArray.c: describe_refs in MVMArray i wasn't able to see if it works, actually ... |
|||
| arVM: 40ae855 | timotimo++ | src/6model/reprs/MVMCompUnit.c: describe refs of MVMCompUnit |
|||
| arVM: d78a5e3 | timotimo++ | src/6model/reprs/SCRef.c: Describing SCRef's refs. |
|||
| arVM: 550d3c3 | jnthn++ | src/6model/reprs/MVMStaticFrame.c: Implement describe_refs for MVMStaticFrame. |
|||
| jnthn | timotimo: Got everything except your abortive P6opaque attempt, I think. Plus I did tweaks, cleaned up warnings, etc. | 12:28 | |
| Those make much more clear why some of the leakage | 12:49 | ||
| spesh slots and guards | |||
| However, even with spesh disabled it still leaks | |||
| nwc10 wonders if there is some correlation between nice hats (that are black) and not eating | 12:52 | ||
| [ilmari may have to explain this :-)] | |||
| ilmari | nwc10: what, did you get a black hat and forget eating? | 13:01 | |
| ilmari has already had lunch today | |||
| nwc10 | ilmari++ | 13:03 | |
| no, it was more that IIRC jnthn has a nice black hat, and sometimes forgets to eat | |||
| ilmari | ah | ||
| nwc10 | and I forget whether DrHyde has a had | ||
| er hat | |||
| I have hte bobs | |||
|
13:18
masak joined
|
|||
| masak | for those interested in/curious about SSA, I found www.cs.indiana.edu/~achauhan/Teachi...fnprog.pdf to be very approachable and wirth my reading time | 13:19 | |
| I don't know if it's a "classic paper", but maybe it should be. | |||
| moritz | masak: it's funny that you misspelled "worth" as "wirth" in this context, 'cause one of my former CS profs or TAs was named "Wirth" :-) | 13:23 | |
| masak | oops :) | 13:29 | |
| ...er, not *that* Wirth, though -- right? :P | |||
| masak .oO( I made Pascal, then I worked as a TA for a while ) | |||
| geekosaur | (call by value?) | 13:31 | |
| masak | clearly what moritz was holding was a *reference* to Wirth, but that *reference* is still passed *by value*. yes, I know the terminology is confusing. | 13:33 | |
| moritz | masak: not *that* Wirth, no :) | 13:37 | |
| lizmat | .oO( I'm not Wirthy ) |
13:38 | |
| timotimo "wakes" up | 13:48 | ||
|
13:48
brrt joined
|
|||
| brrt | masak++ | 13:49 | |
| dalek | arVM: e016fef | jnthn++ | src/ (4 files): Include inter-generational roots in heap snapshot. That means snapshots will include things kept alive only by their presence in the inter-generational roots set. |
||
|
14:09
zakharyas joined
15:05
ilmari joined
15:16
ilmari joined
15:22
ilmari joined
|
|||
| jnthn | Damn, hope everyone will close their eyes while I push an embarassing patch in a little bit... :) | 15:26 | |
|
15:26
ilmari joined
|
|||
| timotimo | huh, will inter-gen-roots ever keep things alive that are supposed to die already? | 15:28 | |
| i thought they get cleared out when a major collection happens, or something? | |||
|
15:30
ilmari joined
|
|||
| jnthn | Yes, and we weren't clearing them out properly. | 15:30 | |
| timotimo | !! | ||
| jnthn | The full analysis I've been doing today has turned up various other intresting things we'll need to address, but that one was the whopper. | 15:31 | |
| timotimo | also ... *facepalm* of course spesh candidates will keep old stuff alive via logging, spesh slots, stuff like that | ||
| jnthn | Right, that's the other one. | ||
| Though that does at least saturate. | |||
| timotimo | yeah, but do we actually want it to saturate? | ||
| when types disappear, we'll never get them for our guards | |||
| well, they don't disappear; i mean when they *could* disappear | |||
| and they'll be blocking candidates | 15:32 | ||
| jnthn | Indeed. | ||
| timotimo | ugh, cache invalidaiton | ||
| even typing it is hard | |||
| masak | what I'm hearing from this is that things will get better after the patch, right? because that's all I care about ;) | ||
| jnthn | :P | ||
| masak: Yeah, they will... Since this is a patch touching the GC, it's getting some careful testing before it lands :) | 15:33 | ||
| masak | yes, of course | ||
| timotimo | jnthn, did i show you what the profiler looks like for splitting a huge string into small-ish chunks? in particular the GC tab ... | ||
| jnthn | I've been writing up my investigations as I go, so they'll land in a 6guts post at the weekend or so | ||
| masak | whee | ||
| jnthn | timotimo: Don't remember so | ||
| timotimo | OK ... | ||
| basically it's a few hundred runs of 1/3rd red, 2/3rd orange and then 2/3rds red, 1/3rd orange over and over | 15:34 | ||
| we may want to have some kind of adaptive tuning for the case where there's more than half orange | |||
| because all those string objects ended up going straight to gen2, but they cause a lot of space in the nursery to get blocked (every second time, at least) | 15:35 | ||
|
15:38
ilmari joined
|
|||
| timotimo | actually, the person who owns the benchmark that did that suggested "can we turn off the GC somehow?" and that might even be a good idea for our implementation of split when it notices it's making a gigantic amount of Str objects | 15:38 | |
| jnthn | Yeah, everything builds OK with my patch | 15:46 | |
| CORE.setting builds a little slower ('cus we're doing proper full collects, presumably), but with around 40MB less memory use | |||
| And the EVAL in a loop platteaus. | 15:47 | ||
| timotimo | \o/ | ||
| it plateaus how soon? | |||
| didn't it use to plateau, too, just after a surprisingly long time? | |||
| jnthn | No | ||
| It kept growing forever because of the GC bug I'm about to push a patch for | 15:48 | ||
| dalek | arVM: 7f2a6fa | jnthn++ | src/ (2 files): Fix a full vs. partial collection detection bug. We detected it in two different places, repeating the same, factored out, calculation. Unfortunately, the outcome could change between the two places, leading to us failing to clean up the inter-generational roots set. This could in turn lead to ever-growing memory use for various kinds of program. |
15:50 | |
| timotimo | oh, is_full_collection looked at the "size of stuff added since last full collection"? | 15:51 | |
| and that was cleared in between? | |||
| jnthn | Yeah | ||
| timotimo | well, i implemented that counter, so it's probably partially my fault :) | ||
| jnthn | So we never did all aspects of a full collect :/ | ||
| timotimo | man, i'm glad you found that | ||
| jnthn | Well, found a few things along with it too, but yeah, that was the worst of it :) | 15:52 | |
| I wonder if this fixes Skarsnik's leaking program too | |||
| japhb | jnthn: I wondered why you focused on leaks so heavily first. Now I know why. Thank you for making the right decision. :-) | 15:53 | |
| jnthn | japhb: Also 'cus long-running concurrent things that juggle mostly IO-bound stuff *is* a place where Perl 6 performance isn't really an issue (and Perl 6 has nice things for doing that), but leaks would be. | 15:55 | |
| One other thing that's probably worth doing now that we have unmanaged_size is pondering factoring it in to the count that decides "when to gen2" | 15:57 | ||
| timotimo | ah, that's like my previous attempt to have "string pressure" | ||
| jnthn | An EVAL loop can create fairly large data structures that then go away, so we'd want to full collect more often to do so. | ||
| Whereas compilation is mostly producing a lot of small objects that get promoted | 15:58 | ||
| So we can't raise the "enough promoted to collect" threshold too high at the moment for fear of large unmanaged size causing a problem | |||
| While if we factor that in, we can bump it a bit further | 15:59 | ||
| timotimo: Yes, that'd be an example :) | |||
| So I may work on that next. :) | |||
|
16:00
ilmari joined
|
|||
| jnthn | Actually I'm getting a mild headache so it's probably time for a break and some dinner :) | 16:04 | |
| So will continue with that later or so :) | |||
| timotimo | have a good one! :) | 16:05 | |
|
16:07
vendethiel joined
16:41
leont joined
17:09
ilmari joined
17:12
ilmari joined
17:19
ilmari joined
17:20
zakharyas joined
17:52
leont joined
|
|||
| dalek | arVM: e95ed88 | jnthn++ | src/gc/collect.c: Factor unmanaged size into promoted bytes. So that objects that hold onto a lot of memory indirectly will have it accounted for, so we can manage memory more smartly. |
18:59 | |
| MoarVM: 6112aaa | jnthn++ | src/gc/ (2 files): | |||
| MoarVM: A (hopefully) smarter when-to-full-collect scheme. | |||
| MoarVM: | |||
| MoarVM: This allows for a slightly lower bound on small heaps, and better | |||
| MoarVM: throughput on big heaps, by using percentage growth to decide when | |||
| MoarVM: to collect. | |||
| jnthn | So the fix cost us a bit on CORE.setting build time, but decreased the memory it took a bit. | 19:15 | |
| The above two patches between them get us that time back, without giving much of the memory win | 19:16 | ||
| And also makes my leaking example from before now top out around 100MB lower. :) | |||
| Enough for today... :) | |||
| timotimo | mhm mhm | 19:18 | |
|
20:34
colomon joined
20:42
brrt joined
21:33
colomon joined
21:35
cognominal joined
|
|||