[Python-Dev] Garbage collector problem

[Jeremy Hylton]

>>>>> "KJ" == Kevin Jacobs <jacobs@penguin.theopalgroup.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.

Jeremy