> Oh, I don't expect it to help appreciably - which is why I never did it ;-)  It's aimed at something different, I think, than what you're after:  reducing the burden of cyclic gc on objects that would otherwise soon be reclaimed by refcounting anyway.  But such stuff is going to get reclaimed "soon" regardless, and saving it from getting scanned by gc at most once has limited potential.

What I wanted to say is that this idea is still interesting to benchmark and experiment on its own, especially because is simple enough.

>You seem aimed more at reclaiming _cyclic_ trash sooner.  The hack I sketched would only help with that if a cycle in part B became "theoretically dead" before part A filled up enough to trigger another collection.  But I have no guess as to the distribution of cycle lifetimes, other than that it's bound to vary a lot across programs, and will be multi-modal.

That is right (I was also looking to solve the case in which an object is referred by something in an older generation, then is promoted and almost immediately the referent dies - or it was dead to begin with -).  I think evolving from your proposal into something in which the first generation is split into two "sub-generations" with the same threshold that is collected at the same time should not be very complicated.