Queue cleanup

Paul Rubin no.email at nospam.invalid
Mon Aug 30 02:52:38 CEST 2010

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
> You can add cycle detection to a reference count gc, at the cost of more 
> complexity.

But then it's not purely a refcount gc. ;)

> If you read the Wikipedia article I linked to, tracing algorithms can 
> also be unsound:  [describes "conservative" gc]

Yeah, whether that counts as a real GC is subjective too.

>> and 2) it requires constant attention from the mutator to incr and
>> decr the reference counts.
> Yes. And?

I thought I made it clear, the purpose of gc is to improve programmer
productivity and program reliability by relieving the programmer from
the burden of memory allocation bookkeeping.  If the programmer has to
painstakingly manage refcounts by hand and the resulting programs are
still prone to refcount bugs (both of which are the case with CPython),
it's not really gc in a way that lives up to the name.

> That's a problem with the CPython API, not reference counting. The 
> problem is that the CPython API is written at too low a level, beneath 
> that at which the garbage collector exists, so naturally you have to 
> manually manage memory.

Care to give an example of a reference counted system that's written any
other way?

> On the other hand, tracing gcs have their own set of problems too, mostly 
> due to the use of finalizers and attempts to make garbage collection run 
> more predictably. See here:

I think it's fairly common wisdom that finalizers and gc don't interact
very well.  Finalizers in general aren't in the gc spirit, which says
the system should give the illusion that every object stays around
forever.  As for stuff like hash tables, a usual way to help out the gc
is by populating the hash table with weak references, rather than by
clearing it out manually when you're done with it.  It's also possible
for fancy compilers to use a mixture of gc and stack- or region-based

> Tracing garbage collectors aren't a panacea. They're software themselves, 
> and complex software, which means they're subject to bugs like the one ...

You could say the same thing about compilers instead of gc's.  The idea
in both cases is yes, they're complex, but they put the complexity in
one place, so that the application program can rely on the complicated
gc or compiler features while itself staying simple.  

More information about the Python-list mailing list