RetroSearch Browse

Mon Apr 2 20:37:41 EDT 2001 · http://mail.python.org/pipermail/python-list/2001-April/089843.html

"David Allen" <mda at idatar.com> writes:

> In article <lclmpj543v.fsf at gaffa.mit.edu>, "Douglas Alan" <nessus at mit.edu>
> wrote:

> >   (1) Why does it use the rather unusual algorithm it does, rather
> >       than a more typical mark and sweep?  The per-object storage cost for
> >       the extra reference count is surely greater than the bit or two
> >       required for a typical mark and sweep.

> Frankly, I'm a bit confused as to why everybody and their brother
> seems to want to implement reference count based garbage collectors
> when better has been available through languages like LISP for
> years.

The fact that Python uses referencing counting for its front-line GC
has some very desirable properties.  Two come immediately to mind:

   (1) Predictable destructor semantics.  This is in contrast to Java,
       in which destructors are useless because you don't know if and
       when they will ever be called.

   (2) No long GC pauses.

You might be able to make a "real garbage collector" that has these
properties, but it would, I believe, be pretty complicated.  You might
be able to get (1) by making the compiler smarter and able to deduce
the lifetimes of most objects.  But this would also be pretty
complicated and might make the compiler too slow.  And it would
still leave you without property (2).

Since referencing-counting typically gets rid of 99.9% of all garbage,
backing it up with a simple mark & sweep GC seems adequate for most
purposes.  I'm just not clear on why Python uses the somewhat unusual
and space-expensive quasi mark & sweep that it uses, rather than a
standard mark & sweep.

|>oug

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-list/2001-April/089843.html below:

A couple garbage collector questions