RE: Re: Garbage collector stopping my world for half a second

["Boehm, Hans" <hans dot boehm at hp dot com>]

> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com] 
> 
> Hans, one of the problems that I found it the the gc doesn't 
> allow fine-grained control over which libraries get 
> registered as roots and which don't.  I fully intend to 
> remove the need for auto-registration of gc roots in libgcj 
> (and I intend to do so soon) but if it's possible in the 
> meantime to scan some subset of shared libraries that would help.
How would you specify those?

You can currently exclude address ranges, but that makes the client do
the hard stuff.  You could try to look for specific library names.  But
the implementation of that would have to be platform-specific, which is
a maintenance issue.  And it's not completely clear to me how you name a
dynamic library.  Pattern matching on the path name?
> 
>  > 2) If that's insufficient, you might try getting the 
> incremental GC to  > work.
> 
> I might point out for the uninitiated that the latter will be 
> very difficult indeed.
I'm not sure we know there are fundamental issues, though it does seem
to require some tricky debugging that nobody has gotten around to.

One issue is that there might be system calls that write to the heap,
and those currently break the incremental GC.  The collector has enough
hooks to make this work if all those calls write only to pointerfree
objects.  (This requires HBLKSIZE == getpagesize(), which is true on
X86, and could be made true elsewhere.  The collector includes a
function to test whether this is safe, so you could just refuse to turn
on incremental GC elsewhere.)

In practice, it's not clear this is a serious issue for gcj.

But based on just setting the GC_ENABLE_INCREMENTAL and GC_PRINT_STATS
environment variables, and running some gcj compiled code, it doesn't
yet work at all, possibly because the various SISGEGV handlers currently
step on each other.  And I think Andrew ran into another harder-to-debug
issue earlier.

I have hear reports that this comes at least much closer to working for
Mono.
> 
> Andrew.
> 
>