Re: status of gcj's boehm collector?

[Jeff Sturm <jsturm at one-point dot com>]

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