[Python-Dev] Garbage collector problem

[Kevin Jacobs]

On Fri, 28 Jun 2002, Jeremy Hylton wrote:
> I had a different ideas to solve this performance problem and perhaps
> others.  It's only half baked, but I thought it was at least worth
> mentioning in an e-mail.  The premise is that the garbage collector
> tracks a lot of objects that will never participate in cycles and can
> never participate in cycles.  The idea is to avoid tracking objects
> until it becomes possible for them to participate in a collectible
> cycle.

Hi Jeremy,

You have an interesting idea, though I'd state the premise slightly
differently.  How about:

  The premise is that the garbage collector tracks a lot of objects that
  will never participate in collectible cycles, because untraceable
  references are held.  The idea is to avoid tracking these objects until it
  becomes possible for them to participate in a collectible cycle.

(virtually any object _can_ participate in a cycle -- most just never do)

Offhand, I am not sure if my idea of ignoring certain references in
generation 0 or your idea will work better in practice.  Both require adding
more intelligence to the garbage collection system via careful annotations.
I wouldn't be surprised if the optimal approach involved both methods.

> How hard would it be to add logic that avoided tracking objects until
> it was plausible that they would participate in a [collectable] cycle?

I can work up a patch that does this.  Can anyone else think of places where
this makes sense, other than frame objects and the ceval stack?

Also, any thoughts on my approach?  I have a hard time thinking of any
situation that generates enough cyclic garbage where delaying collection
until generation 1 would be a serious problem.

-Kevin

PS: The bug Tim spotted makes a big difference too.

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com