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
> 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
More information about the Python-list