Is this a bug? Python intermittently stops dead for seconds

Tim Peters tim.peters at gmail.com
Sun Oct 1 16:37:40 EDT 2006


[charlie strauss]
> Steve, digging into the gc docs a bit more, I think the behaviour I am seeing is still
> not expected.  Namely, the program I offered has no obvious place where objects
> are deallocated.  The way GC is supposed to work is thate there are three levels of
> objects
>
> level0:  newly created objects
> level1:  objects that survived 1 round of garbage collection
> level2:  objects that survivied 2+ rounds of gargbage collection

Yes.

> Since all of my numerous objects are level2 objects,

No.  All newly created objects start in level0.  Over time, most (but
never all) of your objects end up in level 2.

> and none of them are every deallocated, then I should never trip the GC for these.

Cyclic gc scans /all/ container objects at or under level N, whenever
cyclic gc runs.  N varies from run to run of cyclic gc, according to
the scheme described in the docs for the gc.set_threshold() function.
N=2 is certainly a possible value.  There is never a time when a live
container object becomes exempt from all future runs of cyclic gc.  If
a live container object survives two rounds of cyclic gc, it ends up
lin level2.  That doesn't mean it's never looked at again, it just
means it's not looked at during level0 or level1 (N=0 or N=1) runs of
cyclic gc.  It will still be looked at during all level2 (N=2) runs of
cyclic gc.

> Your explanation would require this to be tripped so I can't explain it.  For your
> explanation to be correct then there as to be some non-obvious step in the program
> that is deallocating level2 items in sufficient numbers to trip the GC.

Deallocations never trigger cyclic gc.  As the docs say, cyclic gc is
triggered by an /excess/ of allocations /over/ deallocations.  So,
e.g., if you delete container objects just as fast as you create them,
cyclic gc will never run.  But that's not what you're doing.  Instead
you're allocating new objects but never deallocating them.  That makes
cyclic gc run as frequently as it's possible for it to run.



More information about the Python-list mailing list