Reference counting garbage collection

[Paul Rubin]

"Delaney, Timothy" <tdelaney at avaya.com> writes:
> I believe another major reason is that adding "real" GC would cause problems
> for C extensions. All Python's cycle collector does is break the links
> forming the cycle - the reference counting semantics then handle the rest.

Actually, conventional GC is simpler for C extensions since the C
extensions for the most part don't have to think about the GC.
In the current situation we see a lot of reference counting bugs
in C extensions.

> Java has a "real" GC - and this often leads to problems - in particular,
> programs being relatively fast until a memory threshold is reached - and
> then the GC starts kicking in and things really start slowing down in a
> non-deterministic way. 

That's all a matter of how the GC is implemented.  There are certainly
realtime GC algorithms that have been used in some Lisp and Java systems.

> In tests people have done by replacing Python's reference counting by
> Boehm's collector (reported to this newsgroup) there have been marked speed
> advantages to reference counting in most cases. This is empirical evidence
> that reference counting works well *for Python* in most cases.

I guess that might be the case, at least with the current body of
Python programs.  I'm thinking of Python's implementation in terms of
whether it's suitable for large, long-running programs, and it's
not clear whether anyone really writes those in Python.

The combination of RC and GC (or cycle breaking) that's been described
here sounds like a pretty good approach.  It wasn't described in the
Python docs that I read, which described a pure RC system, but that's
ok :).