RE: Boehm-gc with -00

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

I believe that on X86 with hash synchronization and 4K pages (e.g. on a real, non-emulated X86) byte arrays should no longer be getting protected in incremental mode, since they should be treated as pointerfree.  This changed with 6.1alpha3, which I think has been fully integrated into the gcc tree.

The right solution should be to turn on incremental GC only if

!(GC_incremental_protection_needs() & GC_PROTECTS_PTRFREE_HEAP)

Of course none of this has really been tested ...

Also note that

- You will need to either turn off thread local allocation somehow (probably at build time, yucch), or run the collector in fully conservative mode (possibly at run-time), for this to work.  Otherwise there are scenarios in which the marker sees a bad mark descriptor in an object being allocated.

- Incremental mode currently doesn't get along very well with the parallel GC.  You probably want to turn on at most one, i.e. you usually want to turn on just parallel GC .  (It's actually not 100% clear what this should do.  I think the collector currently reverts to basically parallel + generational, but not incremental mode when you try this.)

- There is currently no way to run the incremental collector without generational collection.  Given the algorithm we're using, it's not clear that it makes much sense to do so.  (See Boehm, Demers, Shenker, "Mostly Parallel Garbage Collection", ACM SIGPLAN '91 Conference on Programming Language Design and Implementation.)

Hans 


> -----Original Message-----
> From: Adam Megacz [mailto:gcj@lists.megacz.com]
> Sent: Friday, May 31, 2002 3:24 AM
> To: java@gcc.gnu.org
> Subject: Re: Boehm-gc with -00
> 
> 
> 
> Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> > By default the libgcj GC is currently not incremental. You can turn 
> > the incremental mode on, but it interacts badly with 
> libjava's IO code 
> > (search the archives for the full story).
> 
> I should note that this isn't hard to fix, though. I had it working
> under Win32 for a while by tweaking natFileDescriptor to read() into a
> stack-allocated or malloc()ed buffer (depending on size) and then copy
> from there into the byte[].
> 
> Hrm, could we make this a configurable on the trunk? I can write up a
> patch for it.
> 
>   - a
> 
> -- 
> Sick of HTML user interfaces?
> www.xwt.org
>