[Python-Dev] GC Changes

Greg Ewing greg.ewing at canterbury.ac.nz
Tue Oct 2 02:37:43 CEST 2007


Justin Tulloss wrote:
> Is the trend going to be to 
> move away from reference counting and towards the mark-and-sweep 
> implementation that currently exists, or is reference counting a firmly 
> ingrained tradition?

It's hard to predict the future, but the general feeling
I get is that many people would like to keep the current
reference counting behaviour, because it has a number of
nice properties:

* It's cache-friendly - it doesn't periodically go
   rampaging through large chunks of memory like
   mark-and-sweep tends to do.

* It tends to reclaim things very promptly. This is
   important in a language like Python that uses
   dynamic allocation extremely heavily, even for
   trivial things like integers. It also helps with
   cacheing.

* It's easy to make it interoperate with external
   libraries that have their own ways of managing
   memory. You don't have to take special steps to
   "protect" things from the garbage collector.

> Would 
> somebody care to give me a brief overview on how the current gc module 
> interacts with the interpreter

The cyclic GC kicks in when memory is running low. Since
the reference counting takes care of any data structures
that don't contain cycles, the GC only has to deal with
cycles. It goes through all currently allocated objects
trying to find sets whose reference counts are all
accounted for by references within the set. Such a set
must constitute a cycle that is not referenced anywhere
from outside. It then picks an arbitrary object from the
set and decrements the reference counts of all the objects
it references. This breaks the cycle, and allows the
reference counting mechanism to reclaim the memory.

Although the cyclic GC requires passing over large
chunks of memory like mark-and-sweep, it happens far less
frequently than would happen if mark-and-sweep were used
for all memory management. Also, the programmer can
minimise the need for it by manually breaking cycles
where they are known to occur.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+


More information about the Python-Dev mailing list