[gclist] reference counting

[Greg Morrisett]

A few things:

(1) People also ignore the overheads of locking to do reference
counting in a multi-threaded system.  It helps to have atomic
increment/decrement and/or compare & swap, but sadly, few 
machines provide it.

(2) While reclamation *can* be immediate, if you have a large
data structure (e.g., an abstract syntax tree) and the root 
count goes to 0, then you may end up walking and freeing the
whole tree.  To amortize the overhead of this, you may end up
sacrificing "immediate" reclamation.  RC tends to work well
for large, pointer-free objects.

(3) It's also not clear to me that pointer-bump allocation is
as huge a win as people think.  A good non-compacting organization
(as in the BDW collector) can allocate objects almost as fast.
They have the added advantage of not requiring twice the space
as a copying collector and thus can do roughly half as many
collections.  Indeed, Fred Smith and I found that the "wins"
of compaction were blown away by the space overheads of accuracy
(needed header words on objects) and copying.  This was in the
context of a comparison we did for our ML-to-C compiler using
a mostly copying collector (with fast, inlined allocation 
routines) versus the BDW conservative collector.  

-Greg