[gclist] Finalizers & Reference counting.

[David S. Wise]

	From: Neel Krishnaswami <neelk@alum.mit.edu>
	Date: Wed, 21 Aug 2002 12:00:52 -0400 (EDT)

	Charles Fiterman writes:
	> 
	> Reference counting has bugs, it can't deal with cyclic data
	> structures, it has excessive overhead but it has some striking
	> advantages. There are no serious SMP bottlenecks, it never has to
	              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	> stop the world.
	  ^^^^^^^^^^^^^^^

	I'm *certainly* no expert, but don't you need a lock on every object
	to update reference counts atomically? Moreover, modifying an object
	in SMP world means that you have to flush the processor's cache to
	make sure that every processor can see the changes -- and RC demands
	an object modification at every access. Together those seem like they
	would impose fairly severe limits on the scalability of SMP RC.

This is self-advertising, but it is old and might be better known.
No lock is necessary if the reference-count is being
incremented/decremented locally to the object.
Many folks assume that the processor that is doing the counting
must be remote from those shared objects, and is not so.
  -Consider the UNIX file system, where we dread doing  fsck.
  -If you are really thinking main memory, think about a smart RAM.
The synchronization then moves back a level, to delivering a
request to share (or unshare) an object.

David S. Wise, B. Heck, C. Hess, W. Hunt, and E. Ost.
Research demonstration of a hardware reference-counting heap.
Lisp Symb. Comput. 10, 2 (1997 July), 159--181.
   http://www.kluweronline.com/oasis.htm/136324
   http://www.cs.indiana.edu/ftp/techreports/TR401.html

David S. Wise. Design for a multiprocessing heap with on-board reference
counting. In J.-P. Jouannaud (ed.), Functional Programming Languages
and Computer Architecture, Lecture Notes in Computer Science 201,
Berlin, Springer (1985), 289--304. 

(Standard cache-coherency warnings apply.  Write-through is recommended.)