Is this a bug? Python intermittently stops dead for seconds

Tim Peters tim.peters at gmail.com
Sun Oct 1 16:49:33 EDT 2006


[Charlie Strauss]
>>> level0:  newly created objects
>>> level1:  objects that survived 1 round of garbage collection
>>> level2:  objects that survivied 2+ rounds of gargbage collection
>>>
>>> Since all of my numerous objects are level2 objects, and none of
>>> them are every deallocated, then I should never trip the GC for
>>> these.

[Fredrik Lundh]
>> your understanding of generational GC is a bit fuzzy, it seems.
>> that an object is promoted to a higher level means that it's
>> not inspected quite as often as lower-level objects, not that it's
>> never inspected at all.

[Charlie]
> As I understand it, level2 (and level1) objects only undergo gc when
> more than 10 of them is deallocated.  Since I never deallocate, this
> should not be tripped right?

No.  Cyclic gc is triggered by an excess of allocations over deallocations.

> In any case regarding your other comments:

>>> Could you clarify that for me.  GC really has three components
>>> two it:  1) finding and freeing unrefernced memory by refer
>>> refer counts 2)  cycle removal and 3)  defragementing the
>>> storage stack.  If I turn off GC, don't I lose all of these?

>> CPython always does (1), only does (2) if cycle-breaking GC isn't
>> disabled, and never does (3).

> Never does 3?

Correct.

>  then how does it compact it's memory allocation area?

It doesn't.

> Surely it does not rely on the OS to manage every small object as a
> separate memory allocation.

It doesn't do that either.  Python has its own small-object allocator,
carving up 256KB chunks obtained from the system malloc().  It's based
on size-segregated "pools" with extremely low bookkeeping overhead,
and external fragmentation in small-object memory is essentially
non-existent because of that (although it's possible to concoct
pathological programs that exhibit it).

> And just to be clear: are you saying that when I do a gc.disable this
> only turns off 2 and not 1?

Right.  Refcounting (#1) can never be disabled, and cyclic GC (#2) is
used only for trash objects that can't be reclaimed by #1 (meaning
container objects in cycles).



More information about the Python-list mailing list