Reference counting garbage collection

[plakal at nospam-cs.wisc.edu]

Paul Rubin <phr-n2001 at nightsong.com> wrote:
> Is there any particular reason Python uses reference counting garbage
> collection (which leaks memory if there's circular structure) instead
> of Lisp-style garbage collection?  As Python gets used for more large
> application development, it gets troublesome to make the programmer
> worry about whether the data has cycles.  Also, using a compacting GC
> helps localize memory references, speeding up the program by improving
> cache performance.  As CPU's get faster and memory doesn't, the cycle
> cost of a cache miss continues to increase.  So maybe the GC
> implementation should be revisited at some point.

  [Reposted from an old mail I sent to gclist at iecc.com a while back]

  To quote some advantages of ref-counting from the GC Book of Jones & Lins:

      - naturally incremental algorithm, no need for a disruptive
	and time-consuming global reachability analysis (which people 
        have been spending ages to optimize), hopefully this improves 
        cache/VM behavior

      - work done is proportional to number of mutator operations                  
	rather than size of live data, this is important for large heaps

      - immediate reclaiming of garbage and finalization (of
        course, you're screwed if you have a cycle of finalizers)

      - recycling of recently allocated memory for better locality
	(and perhaps lower allocator high-water marks) 

      - insensitive to heap-residency (tracing algorithms can thrash               
	with increasing heap usage and may require tuning or adaptivity
	of some sort)

   Manoj