[gclist] Finalizers & Reference counting.
David S. Wise
Wed, 21 Aug 2002 12:07:59 -0500 (EST)
From: Neel Krishnaswami <firstname.lastname@example.org>
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.
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.)