GC performance - was Re: [gclist] GC topics

[boehm.PARC@xerox.com]

"[Me:]
> The collector does not need to see pages
> containing such objects.  In many environments they constitute the large
> majority of all allocated memory.  Thus this can greatly reduce the
collector's
> VM footprint.  I don't know how to get the same benefit in a compacting or
> copying collector.
>
[Darius:]
Doesn't the collector have to see them anyway to be able to mark them
in order to prevent them from being deallocated ? Admittedly, they
don't have to be scanned if talking of a conservative GC..."

In a simple collector yes.  However, if the collector cares about VM
performance it should keep the mark bits on separate pages from the objects.
That also sometimes makes it possible to avoid adding an extra word to every
object.  If the mark bits are separate, then only the pages containing the mark
bits need to be resident.  In our case this is roughly 1/32 the size of the
data, and it could be less.  The data page is touched only shortly before we
allocate from it again, when it needs to be touched anyway.

There may be extra cost involved (on the order of 4 or 5 memory references) to
map an address to a mark bit.  In our case, that's mainly work needed for the
pointer validity check anyway.  (Note that this work is almost never needed for
invalid pointers, since most of those fail some very simple check.  It's the
validity checks on valid pointers that are relatively expensive.  That's why
information of the form "this word is not a pointer" is not all that helpful
for typical case performance.)

Hans
Standard disclaimer ...