status of gcj's boehm collector?

Tue Dec 4 20:31:00 GMT 2001

On 4 Dec 2001, Adam Megacz wrote:
> > This isn't an incremental versus generational issue. They both need
> > a write barrier, i.e. some way to determine what has been modified.
>> Really? I'm probably wrong about this, but I thought that a
> generational collector simply tagged objects according to when they
> were allocated, and scanned recently allocated objects more often,
> hence providing better performance for programs that allocate lots of
> short lived objects (ie you don't have to scan the potentially large
> group of long-lived objects every time).

You don't have to scan the older generation _provided it isn't modified_.
That's the rub. Only a write barrier can guarantee an object is
unmodified.
> Hrm, so in the failure case, the GC suspects that a page has not been
> modified, when in fact it has. Worst case, you get a memory
> leak.

Worst case, you prematurely free a live object, because you may miss a
new pointer stored in the older generation.
One solution discussed before is to modify the collector to allocate
pointer-free objects on pages that won't be write-protected. That
should be good enough for libgcj when hash synchronization is enabled.
(Without hash synchronization even primitive arrays aren't pointer-free.)
There's an easier way if you can tolerate a slight overhead in I/O. Wrap
calls to read() so they modify a local (stack-allocated) buffer, then copy
the buffer to heap memory. I think it would be safe even for
multithreaded use, and not require changes to the collector.
Jeff