Hash synchronization patch

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

Here's my current version of the hash synchronization patch.  It passes my
(pretty basic) tests on Linux/X86.  It is against a recent tree, so it
should hopefully apply to the current CVS tree.

Performance impact varies.  I've seen improvements of up to 45% on a toy
multithreaded StringBuffer example.  I don't know of any major performance
regressions at the moment, but I just fixed one that amounted to about a 3
order of magnitude slowdown.  I suspect there are others I haven't found
yet.  YMMV. 

It should be safe to add to the generic tree, though I'm not sure what the
best timing is for that.  Most of it is turned off unless you build with
--enable-hash-synchronization.  You should currently build with
--enable-hash-synchronization only on linux/X86.  If you don't actually turn
on hash synchronization, the patch shouldn't be that risky.  If you do, it
is.  I would hope that in the future --enable-hash-synchronization would
become the default on most standard desktop platforms, though not
necessarily for embedded platforms.  (Architectures without compare-and-swap
or LL/SC need some more work.)

I'd appreciate any further testing and fixes to the configure scripts (see
below).

Note that this also includes a few more generic changes, which are enabled
in all configurations:

1) Reduce the amount of time spent clearing stacks in the GC.  This seems to
be a clear win on linux/X86.  I would hope and expect that it's also a mild
win on other platforms.

2) The collector silently ignores finalization requests on static data.
Needed for hash synchronization, since we sometime synchronize on statically
allocated objects.

3) With gcj style allocation, require objects to have size >= 2 words.
(Hash synchronization needs to steal at least 3 low order bits in an object
address.  Plus gcj object allocation relied on >= 2 word objects to deal
correctly with a subtle race.  A plain Java Object was otherwise only 1 word
for the vtable, which also caused it be only 4 byte aligned.)

4) Some reductions in the allocation path length.  Out of memory checking is
moved into the collector, which is currently built with -fexceptions, though
that's only partially necessary.

Known issues:

1) Configure scripts need to be fixed.  Currently if you build with
--enable-hash-synchronization, you need to subsequently invoke gcj with
-fhash-synchronization.  If you get them mismatched, things die quickly
(since all object layouts are inconsistent).

2) Object.h currently has an "ifndef JV_HASH_SYNCHRONIZATION" in it.  This
is presumably broken if user code includes it.  Configure scripts should be
changed to install one of two versions.

3) The hash synchronization support in natObject.cc is not as portable as I
would like.  It currently includes yet another compare_and_swap implemention
for X86 and IA64.  It relies on some specific characteristics of boehm-gc.
All of this can probably stay for now but needs a better long term solution.
(Ports to other Unix-like platforms should be straightforward.  They're
just not there yet.)

4) boehm-gc.h was modified to allow inlining of _Jv_AllocObj.  The result is
not beautiful, but it buys a few percent on allocation-intensive benchmarks.
The style police should look at this one closely.

5) The Linux/Itanium port was not tested.  The build died for apparently
unrelated reasons before
it got to the relevant code.  I will probably try again with an updated tree
once the Alpha
issue look to be resolved.

Hans

hash-sync.patch