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.

	Just wanted to point out that there's been
	some recent work from IBM Research on a
	concurrent reference-counting collector for Java
	that reclaims cycles but without doing any
	global tracing like mark&sweep or copying
        (it does do some localized tracing but
	not the entire graph of accessible objects).

	This also seems to be one of the few papers
	that does a head-to-head performance comparison
	between ref-counting and mark&sweep (concurrent
	versions):
	  http://www.research.ibm.com/people/d/dfb/papers.html#Bacon01Java

        The collector is a concurrent one aimed at
	a multiprocessor servers, and the description
	of the cycle collector (which uses localized
	tracing) claims that it has better locality
	than global tracing schemes.

	They also claim that in this age of
	ultra-fast processors and slow memory,
	it might be a good tradeoff to spend
	more CPU time doing ref-counting operations
	while improving memory access time
	due to ref-counting's better overall locality
	(no periodic trashing of cache and VM
	system by global tracing of heap).

	Manoj