Garbage Collection in Python - current status of issue?

Neil Schemenauer nascheme at enme.ucalgary.ca
Wed Sep 29 16:05:51 EDT 1999


skaller <skaller at maxtal.com.au> wrote:
>[Neil Uses Boehm conservative collector] 
>
>There are several problems with this approach. The first is
>related to executing __del__ methods. I also built a patch
>for using Boehm, only my code deleted the reference counting
>as well. 

I found that removing the reference counts slowed things down a
lot.  As Tim pointed out, reference counting has good cache and
vm behavior.  It also takes care of freeing resources like file
handles quickly.

>Now, it is non-trivial to execute __del__ methods
>synchronously without reference counting, or to execute
>them properly, when both reference counting _and_ collector
>finalisers are used.

This is true.  With my patch the __del__ methods are called
except for objects that the garbage collector frees.  This is
another good reason not to remove the reference counting.

>The second nightmare relates to the way the collector interacts with
>threads.

Many people don't use threads.

>Interestingly, Viper (my python interpreter/compiler) has a
>different problem altogther. The current implementation uses a
>full scale compacting, incremental, native (non-conservative)
>garbage collector which is thread safe, but which doesn't
>support finalisers. So my problem is not getting GC working, but
>calling __del__ methods.

It is much easier include garbage collection in a new language
then to add it to an existing language.  My patch is not a
perfect solution.  I'd be the first to admit that.

Regarding your finalization problem, perhaps you can use
"Topologically Ordered Finalization" like the Boehm collector
does:

    http://reality.sgi.com/boehm_mti/finalization.html

This seems to handle the problem of calling finalizers in a sane
order.  With this approach finalizers are not called on objects
that form cycles.  This shouldn't be a problem if finalizers are
used sparingly.  I think you could work around the problem of
cycles too (maybe call a random finalizer, remove the finalizer
and do another mark pass).

I am looking forward to seeing Viper.  When are you planning on
releasing some code (if at all)?  Sam Rushing's Lunacy
(www.nightmare.com) also looks quite interesting.  The more the
merrier, I say. :)


    Neil




More information about the Python-list mailing list