[gclist] reference counting

[Henry G. Baker]

> At 2000-09-05 11:20:05+0000, Greg Morrisett writes:
> > (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.
> 
> In MLWorks, most collections of young generations have the property
> that almost nothing survives (5-15%), so most of to-space is never
> touched, so it need only exist in VM.  VM is just disk space, which is
> insanely cheap.  If you like living dangerously, with an
> over-committing VM system, then VM is even cheaper than that (until
> one day, when you really need it, and it's not there at all).
> 
> Nick B

A very nice paper a few years ago showed that if:

1) you used a "pointer-bump" (contiguous) allocation GC and
2) you had a "write-allocate" cache,

then a large fraction of allocations would live and die completely
in the cache, and never cause any memory references or disk traffic
at all (remember: only _live_ objects are touched by the GC).  I'm
not sure that refcount can ever compete with this kind of efficiency.

Henry