[gclist] reference counting
Henry G. Baker
Wed, 6 Sep 2000 03:21:19 -0700 (PDT)
> 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.