Python's garbage collection was Re: Python reliability

[Alex Martelli]

Tom Anderson <twic at urchin.earth.li> wrote:
   ...
> Has anyone looked into using a real GC for python? I realise it would be a

If you mean mark-and-sweep, with generational twists, that's what gc
uses for cyclic garbage.

> lot more complexity in the interpreter itself, but it would be faster,
> more reliable, and would reduce the complexity of extensions.

???  It adds no complexity (it's already there), it's slower, it is, if
anything, LESS reliable than reference counting (which is way simpler!),
and (if generalized to deal with ALL garbage) it might make it almost
impossible to write some kinds of extensions (ones which need to
interface existing C libraries that don't cooperate with whatever GC
collection you choose).  Are we talking about the same thing?!


> So python doesn't use the old SmallTalk 80 SmallInteger hack, or similar?
> Fair enough - the performance gain is nice, but the extra complexity would
> be a huge pain, i imagine.

CPython currently is implemented on a strict "minimize all tricks"
strategy.  There are several other implementations of the Python
language, which may target different virtual machines -- Jython for JVM,
IronPython for MS-CLR, and (less mature) stuff for the Parrot VM, and
others yet from the pypy project.  Each implementation may use whatever
strategy is most appropriate for the VM it targets, of course -- this is
the reason behind Python's refusal to strictly specify GC semantics
(exactly WHEN some given garbage gets collected)... allow such multiple
implementations leeway in optimizing behavior for the target VM(s).


Alex