[Copying response to gc mailing list.]

6.8 is old at this point, but this hasn’t changed much in 7.2alpha6.

The collector always stores mark bits in a map off to the side.  When I last looked at this ages ago, that seemed to be a clear win.  We need to look up a page descriptor for the object being marked in any case.  Thus the overhead is smaller than it would probably be for a non-conservative collector.  Having the mark bit in the object, or even on the same page, would mean accessing pages containing pointer-free objects during a GC.  In my experience, in well-tuned applications, a large fraction of the heap is pointer-free.  The GC could often touch twice as many pages during a GC with the mark bits in the objects.

An ancient version of the GC stored mark bits at the beginning of each page.  That potentially  causes other cache-related problems.  All mark bits contend for a small fraction of the cache.

The GC allocates memory from a free-list, but free-lists are built only a page at a time, when needed.  Building the free-list will force memory into the cache, but the hope is that it will still be there when the object is allocated by the client.

Hans