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