status of gcj's boehm collector?

Fri Dec 7 14:22:00 GMT 2001

> -----Original Message-----
> From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
>> Boehm, Hans wrote:
>> >Depending on your application, hash synchronization may also have a
> >substantial effect, since it allows pointerfree objects. 
> Currently that's
> >supported only on some Linux platforms in 3.1. 
> >
>> Is it worth doing a fallback, portable hash-sync implementation that 
> uses the platform's locks, for when we don't have an inline 
> compare-and-swap?
>Probably. I think you would slow down synchronization appreciably. But for
some applications it probably still wins.
I started looking at the collector changes required to not protect
pointerfree objects, so that we could enable incremental GC. It looks like
in the initial implementation at least, this will only work if the
collector's heap block size matches the page size. (The collector already
requires that the page size be a multiple of the heap block size.) Since
X86 seems to pretty much fix the page size at 4K, it's not an issue there.
For other architectures which don't fix the page size it may be an issue
since the garbage collectors block size is (and I think has to be, for
performance reasons) a compile-time constant. The right thing to do for now
is probably to ignore incremental GC requests if the machine has the "wrong"
page size.
Fixing this correctly would require segregating pointerfree and other memory
regions, so that they never, or very rarely, share a page. This is
possible, but nontrivial, and has implications on fragmentation.
Hans