Re: status of gcj's boehm collector?

[Adam Megacz <gcj at lists dot megacz dot com>]

"Boehm, Hans" <hans_boehm@hp.com> writes:
> > generational/incremental GC with a page-protecting write barrier.

> This shouldn't be on by default. ...  There should probably be a way
> to turn it on directly from Java code.

Sounds good.


> > 2. Since all system calls will be made via natXXX.cc in libgcj, add
> >    code to switch page protection for the target page off just before
> >    system calls, and then switch it back on afterwards (if it was
> >    enabled beforehand, of course).

> We've been there.  The wrappers to do approximately that are currently in
> the GC.  Unfortunately, to do this correctly you need to acquire a lock or
> provide some other form of synchronization.  Currently the allocation lock
> is held while the system call is executed.  This is very unfortunate if the
> call blocks.

So, using the scheme you outline below, I assume that all system calls
will be writing to PTRFREE objects, which are allocated on unprotected
pages?


> 1) Make sure hash synchronization works on interesting platforms.  (For
> win32, I think much of the effort there will be finding a fast way to
> compute a thread id, probably by porting the Linux code.  Or does win32 also
> use a segment register to hold some sort of thread pointer?)
> 
> 2) CNI code and the runtime are only allowed to make system calls that write
> to static data, stack memory, malloced objects or pointerfree objects in the
> heap.  The latter is guaranteed to include primitive arrays.  (We refuse to
> really turn on incremental GC unless hash synchronization is available.)
> This still restricts CNI, but in a way that I think is easier for a
> programmer to remember, and probably automatically satisfied in most cases.
> 
> 3) Change the collector so pointerfree objects are not protected.  I will
> take care of that.

Yes, this seems much more elegant.

This is starting to look much more attractive. I'll make hash
synchronization on win32 a priority for myself -- if I can get that,
we'll have (1) on the two biggest platforms (win32, linux).

Can anybody comment on how close (2) is to already being true?



> > 4. When System.gc() is manually invoked by the application, always
> >    perform a full heap scan (and reset numIncrementalCollections).

> I think that's already what happens.  (The other theory is that you should
> ignore it completely, since that speeds up the average application.  I'm not
> sure that's a bad theory either.  It's probably best to just to discourage
> use of System.gc(), so that it doesn't matter.) 

In that case, how would a latency-sensitive application signal the GC
that it is now "okay" to stop-the-world for a long time (ie perform a
full heap scan)?

I thought that was the whole point of System.gc() -- it might not
actually cause a GC; it's just a hint to the GC that "now is a safe
time to pause the application for a while". Sorta like Thread.yield().

  - a