"KJ" == Kevin Jacobs email@example.com writes:
KJ> You have an interesting idea, though I'd state the premise KJ> slightly differently. How about:
KJ> The premise is that the garbage collector tracks a lot of KJ> objects that will never participate in collectible cycles, KJ> because untraceable references are held. The idea is to avoid KJ> tracking these objects until it becomes possible for them to KJ> participate in a collectible cycle.
I guess the untraced reference to the current frame is the untraceable reference you refer to. The crucial issue is that local variables of the current frame can't be collected, so there's little point in tracking and traversing the objects they refer to.
I agree, of course, that the concern is collectible cycles.
KJ> (virtually any object _can_ participate in a cycle -- most just KJ> never do)
Right. There ought to be some way to exploit that.
KJ> Also, any thoughts on my approach? I have a hard time thinking KJ> of any situation that generates enough cyclic garbage where KJ> delaying collection until generation 1 would be a serious KJ> problem.
If I take your last statement literally, it sounds like we ought to avoid doing anything until an object gets to generation 1 <0.7 wink>.
Your suggestion seems to be that we should treat references from older generations to newer generations as external roots. So a cycle that spans generations will not get collected until everything is in the same generation. Indeed, that does not seem harmful.
On the other hand, it's hard to reconcile an intuitive notion of generation with what we're doing by running GC over and over as you add more elements to your list. It doesn't seem right that your list becomes an "old" object just because a single function allocates 100k young objects. That is, I wish the notion of generations accommodated a baby boom in a generation.