Circular references and python

[Tim Peters]

[Neel Krishnaswami]
> ...
> I think a lot of people are working with severely outdated notions of
> the performance of of garbage collectors. Even 16 or 17 years ago
> garbage collection was expensive enough that Lisp Machiness made it
> something you ran manually every few days.
>
> But the state of the art has improved hugely: in _Compiling with
> Continuations_, Andrew Appel claims that a well-tuned generational
> garbage collector is competative with stack allocation in terms of
> speed, for functional and OO languages. (IIRC, SML/NJ allocates even
> activation records on the heap, and wins doubly because this
> simplifies the runtime.)

Speed isn't the hangup in the Python world.  It's much more ease of porting
to new platforms (the amount of time spent now on porting CPython's gc: 0),
and CPython's extraordinary friendliness to extending and embedding.
JPython inherits Java's "real gc", and you need only visit the JPython
archives to see the jealousy of CPython's ability to talk to the rest of the
world <0.3 wink>.  Any scheme that relocates objects (generational or
otherwise) will almost certainly never happen in CPython for that reason;
ditto any scheme that requires CPython to carve up the address space (part
of being maximally friendly is living with whatever the heck the platform
malloc feels like doing).

I don't expect reference counting will ever go away in CPython (too many
people like its relatively predictable semantics. too), although I do expect
*some* way to reclaim cycles (at unpredictable times) will eventually be
added.

no-pure-wins-ly y'rs  - tim