Hash synchronization patch, version 3

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

I've attached the latest version of the hash synchronization patch.  This
should be a complete patch.

I now believe that if you

0. Start out on a Linux/X86 machine
1. Start with today's CVS tree
2. Apply Per's two patches from last night
3. Apply the attached patch
4. Configure the resulting tree with --enable-hash-synchronization
5. Subsequently always invoke the generated gcj with -fhash-synchronization,
and
6. Don't use cni just yet

You should get working executables which are likely to run faster than
before.

I also believe that if you build and compile as before, nothing should
break.  If other people can verify this, I'd like to see this checked into
the development tree after the configure scripts after problems (1) and (2)
below are fixed.  (I'm hoping that an auto* expert can handle those
quickly.)  I don't currently know of any reason not to make
--enable-hash-synchronization the default for Linux/X86.

This has several more minor bug fixes relative to version 2.  It should run
"hello world" with or without hash synchronization on Itanium, though I
can't do any real testing there at the moment, due to other problems.

This includes some patches that should perhaps also go into the 3.0 branch:

gcconfig.h, os_dep.c: Itanium fixes.  Needed for recent kernels.
(Unfortunately, the patch breaks things on the user-level simulator.  But
that doesn't support threads anyway.)

gcj_mlc.c: Fixes a serious bug in a currently unused function.  Hence very
low risk.

linux_threads.c: Fix a typo in currently unused code.  Save some useful
information in globals to allow debugging of what appear to be very rare
failures in the thread stopping code.

Hans


Most of the comments from my initial announcement still apply.  The still
relevant pieces follow:

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. 

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.  (It's slightly less risky, now, since it has more mileage on it.)  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.

hash-sync-v3.patch