[gclist] Unreal

[Hans Boehm]

On Jul 18, 12:40am, David Chase wrote:
> Subject: Re: [gclist] Unreal
> At 03:56 AM 7/18/99 +1200, Nigel Bree wrote:
>
> >In my own collector, I store mark bits separate from objects, in a
bit-vector
> >local to the collection. While in my case the (C++ based) objects and indeed
> >program footprint is small enough to make this unnecessary, I do it as a
> >cautious measure to avoid causing VM stress - although any even partially
> >conservative collector is likely to stress the VM system, I figure a mark
bit
> >in the object header is likely to be unhelpful overall. I await correction
> >from Hans, David Chase et al. :-)
>
> Uh, no.  I think storing the mark bits separately is a good idea.
> You do win somewhat on locality of writing cache
> lines/pages, and you also protect yourself somewhat from C/C++
> accidents in which you overwrite collector data structures
> (collector bugs are bad enough without that additional hair).
> It also gives you somewhat more freedom to fiddle with your
> collector without changing your object format, which might
> matter to you in a big C/C++ system.
>
I agree completely.  In many situations the argument is actually quite a bit
stronger than that.  Consider a program with a simple
mark/sweep-during-allocate collector that keeps something like 20MB live data
in a 30 MB heap.  Assume that 75% of the live heap data is pointerfree.  (These
numbers were fairly typical for the Xerox Cedar environment, YMMV.)  With
pointerfree objects segregated, and mark bits in a separate small region, the
client may be able to run without paging in as little as 15MB of physical
memory.  (This assumes we never allocate on partially full pages, an
unrealistic assumption.  But nonetheless many pages will never be allocated on.
 And if we do get paging, it will more likely be in the form of short bursts
related to allocation instead of major hiccups during GC.)  The experience with
Cedar ws that this made a huge difference.

As far as I can tell, this issue is almost completely unrelated to whether the
collector is conservative, so long as you use a (mostly) nonmoving collector
for old objects.  And that appears to be generally a good idea for reasons
similar to the above.

Hans


-- 
Hans-J. Boehm
boehm@sgi.com