dalek_p6c | arVM: 4bf289a | hoelzro++ | src/io/fileops.c: Don't resolve symlinks by hand Let the operating system resolve them for us, because it knows best. |
00:14 | |
arVM: d3559f9 | hoelzro++ | src/io/fileops. (2 files): Remove MVM_file_stat_follow_symlink It's no longer used |
|||
jnthn | \o/ | 00:17 | |
01:26
jimmy2 joined
01:32
JimmyZ_ joined
02:30
vendethiel joined
02:52
JimmyZ_ joined
03:19
JimmyZ_ joined
03:41
JimmyZ_ joined
03:47
vendethiel joined
04:08
JimmyZ__ joined
06:23
vendethiel joined
06:54
vendethiel joined
06:58
dalek joined
08:04
rurban_ joined
08:05
vendethiel joined
08:38
dalek joined
09:31
woolfy left
10:05
dalek joined
|
|||
JimmyZ | \o | 10:07 | |
jnthn: I have a pull request for rakudo/roast :) | 10:08 | ||
12:23
terrencehan joined
12:25
terrencehan left
13:09
jnthn joined
14:01
JimmyZ joined
|
|||
timotimo | jnthn: should i invest some time and energy to trying to figure out what kinds of things end up with gen2 roots pointing to them? | 16:19 | |
especially for core setting compilation | 16:20 | ||
jnthn | timotimo: If you can just dump out the REPR names and counts of them that'd help us enough, I think. | ||
timotimo | it seems like that should boil down to iterating over the gen2 roots list in a tiny shred of C code | 16:21 | |
jnthn | Right | ||
And just dump the output and hack up a script to analyze it | |||
timotimo tries | |||
jnthn | My suspicion is it's going to be a lot of MVMCode | ||
nwc10 | I missed the backstory on this - I assume that there's an interesting reason for this, but I'm utterly failing to guessit | ||
timotimo | could be | 16:22 | |
jnthn | nwc10: There's not really much backstory | ||
nwc10 | ah OK - so, what does finding this out let us improve? | ||
timotimo | oh, my time is being cut short | ||
maybe i'll try later today | |||
jnthn | Well, it would confirm my hypothesis that the issue is that frames don't play in the generational model | 16:23 | |
And so if we end up with a gazillion closures alive, and those have to kept in the inter-gen list for now (which promises safety), we can end up with the inter-gen list getting huge. | |||
Gotta go...bbiab | |||
16:23
ChanServ joined
|
|||
timotimo | not 100% sure how the frames fit into the gc story | 16:25 | |
jnthn: not really sure if i've done it right: gist.github.com/timo/f00e026fa5c59ddc9ee9 | 16:41 | ||
16:46
zakharyas joined
17:56
rurban_ joined
17:57
flussence joined
17:58
flussence joined
18:00
flussence left
18:17
flussence joined
19:10
FROGGS__ joined
|
|||
timotimo | all i can say is: that seems like awfully little stuff | 19:58 | |
so it may be the frames rather than the items that cause stuff to balloon up | |||
yeah, the number of frames in the gen2 worklist reaches 50k during core setting compilation | 20:04 | ||
oh | 20:05 | ||
now the number of things i salso much, much bigger | |||
gist.github.com/timo/f00e026fa5c59ddc9ee9 - updated with probably correcter numbers | 20:14 | ||
to be honest, i don't really know what SCRefREPR'd things ... are | 20:15 | ||
20:29
colomon joined
|
|||
timotimo | gist.github.com/timo/f00e026fa5c59ddc9ee9 - updated to have the frames: lines in it, too | 20:51 | |
jnthn | What the heck, why SCRef 120608 times?! | 21:01 | |
Surely that can't be right. The inter-gen worklist is not meant to have dupes. | 21:03 | ||
And we can't be creating that many SCs. | |||
21:06
zakharyas joined
|
|||
timotimo | mhh | 21:10 | |
jnthn | I can't find any fault with your patch | 21:11 | |
oh... | |||
But I did mis-understand what the data means. | 21:12 | ||
OK, it kinda makes sense. | 21:14 | ||
Because what's in the list is *pointers* that need updating. | 21:15 | ||
dalek | arVM: 5380cee | jnthn++ | src/gc/roots.c: Avoid some duplicate work in inter-gen roots. The intermediate worklist already filters gen2 things out, so we do not need to re-validate this. And the flag fiddling for the main worklist is bogus; we only put nursery things on it (this may be a leftover from an earlier design). |
21:37 | |
jnthn | Doesn't yield much of note, but a worthwhile cleanup | 21:38 | |
timotimo: The thing is, MVM_gc_root_add_gen2s_to_worklist actually visits the gen2s and marks all of them | 21:44 | ||
timotimo: So what we're learning here is that the intergenerational roots point to, rather than what they *are*. | |||
timotimo: Which is interesting, though not the same. | 21:45 | ||
timotimo | ah | 21:57 | |
so really i'd want to instrument he write barrier to find ou twhat gets added to gen2 roots? | |||
jnthn | o | 21:59 | |
*no | |||
Just need to loop over tc->instance->gen2roots | 22:00 | ||
uh, sorry | |||
tc->gen2roots | |||
dalek | arVM: ffac8fa | jnthn++ | src/gc/roots.c: Avoid some copying handling inter-gen roots. We used to handle this by putting the entries onto a temporary list, then copying them and counting if there were any. There's an easier way, though: just look at the worklist size before and after. Again, not much impact from this, but it avoids some work. |
22:02 | |
jnthn | Not to mention the code is simpler :) | ||
timotimo | yays | 22:50 | |
i can make that change work | |||
this takes long | 22:57 | ||
yup, here's the results | |||
jnthn: gist.github.com/timo/6b21aad669233881509a | 22:58 | ||
as you guessed | |||
so, you're gonna fix it, right? :) | 23:04 | ||
23:10
ChanServ joined
|
|||
timotimo | because TBH i don't know what's causing this | 23:20 | |
MVMCode doesn't get moved into gen2 for some reason? | |||
23:28
ChanServ joined
|
|||
jnthn | timotimo: It does get moved into gen2, but since it references a frame, and frames aren't write-barriered at all, then to preserve the generational invariant we put it into the inter-gen set. | 23:32 | |
timotimo: So if we don't want to put it into there, we have to do something else to make sure we're upholding the invariant in question :) | 23:33 | ||
23:36
ChanServ joined
|
|||
jnthn | Anyway, so far as I can tell, the various things are working as designed. So it's the design that needs another approach. :) | 23:37 | |
23:59
tgt joined
|