GC changes/enhancements

[Boehm, Hans]

I made some changes in GC version 6.0alpha6 that may eventually impact
libgcj.  This is likely to be integrated into libgcj eventually, though
probably not within the next couple of weeks.  If anyone sees any problems,
please let me know.  I'm mentioning only those that might be controversial.

My plan is to eventually make thread-local allocation and parallel GC the
default for libgcj on platforms like Linux/X86.  I expect this will be
approximately performance neutral in the uniprocessor case, but should
improve performance significantly on a multiprocessor.

More recent changes:
 
1) ALL_INTERIOR_POINTERS is an initialization time option, though the
compile-time flag still affects the default.  It's now determined by a
runtime flag, GC_all_interior_pointers, which must have its correct value at
GC initialization time, and may not change afterwards (since it affects the
construction of some more or less static collector data structures).  The
performance impact seems to be minimal.  (ALL_INTERIOR_POINTERS was always
signifcantly slower on GCBench, but that's almost exclusively due to the
fact that objects are allocated larger, in order to accommodate
"off-the-end" pointers in C.  That difference is preserved.)

What's the right mechanism for setting this?  Probably gcc should build the
library without ALL_INTERIOR_POINTERS.  Any client that needs
ALL_INTERIOR_POINTERS can define some special symbol  which is checked at
startup.  Any C visible version of the library should define that symbol by
default.  I'm not sure I understand the linker rules well enough to design
the right mechanism.

2) The collector now looks at more environment variables, all of which start
with "GC_".  Most of these are primarily useful for debugging (e.g turn off
GC, turn on GC_all_interior_pointers, cause the GC abort routine to loop so
that a debugger can be attached, turn on some minimal logging).  But it also
allows the initial heap size to be set.  Can anyone see any problems with
this mechanism in the libgcj context?  Are gcj applications running as
"root" an issue?  It would certainly be possible to get them to use a lot of
resources, e.g. by turning off the gc.  (There is a build-time option to
disable this, but it would be nice if we didn't have to.)

Hans