[gclist] reference counting

[Nick Barnes]

At 1970-09-06 10:21:19+0000, "Henry G. Baker" writes:
> > 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.

Indeed.  When I was analyzing the death age function for MLWorks, I
measured the nursery survival rate for various sizes of nursery.  As I
recall, with a 4K nursery, the survival rate was well under 40%.

Note that this was prior to some compiler optimizations which reduced
consing (we already did a lot of object allocation on the stack and in
registers).  In fact, all my information about MLWorks is several
years old, and should not be taken as descriptive of the current state
of the product.

Nick B

--
FreeBSD 2.2.8-RELEASE: up 10 days, 15:22
last reboot Sat Aug 26 21:11 (lightning strike)