Queue cleanup

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sat Aug 28 02:24:12 CEST 2010

On Fri, 27 Aug 2010 09:16:52 -0700, Aahz wrote:

> In article <mailman.1967.1281549328.1673.python-list at python.org>, MRAB 
> <python at mrabarnett.plus.com> wrote:
>>An object will be available for garbage collection when nothing refers
>>to it either directly or indirectly. If it's unreferenced then it will
>>go away.
> This isn't actually garbage collection as most people think of it.
> Refcounting semantics mean that objects get reaped as soon as nothing
> points at them.  OTOH, CPython does also have garbage collection to back
> up refcounting so that when you have unreferenced object cycles they
> don't stay around.

I've repeatedly asked, both here and elsewhere, why reference counting 
isn't "real" garbage collection. Nobody has been able to give me a 
satisfactory answer. As far as I can tell, it's a bit of pretentiousness 
with no basis in objective fact.


Reference counting is one specific kind of garbage collection, and like 
all gc strategies, it has strengths as well as weaknesses. It is *simple* 
to implement (which may be why a certain class of programmer likes to 
think it isn't "real" gc). When it runs is deterministic, and is 
immediate upon the resource being freed. The overhead is very light (a 
plus) and continuous (which can be both a plus and a minus). It is better 
suited to managing scarce resources like open files than are tracing 
garbage collectors. It avoids the "embarrassing pause" of tracing 
collectors. It doesn't deal well with reference cycles, and (at least 
with Python's implementation of ref counting) it causes performance 
issues with threaded applications.


So CPython has two garbage collectors -- a reference counting 
implementation, and a tracing implementation. Jython and IronPython use 
the native garbage collectors from Java and .Net. Other Pythons may use 
something else.


More information about the Python-list mailing list