Re: Alignment problem with hashtable locks on PowerPC

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Boehm, Hans wrote:

>I would definitely try that.  It cold make a substantial difference. 
>

Will do. Another thing I notice is that the assertions in 
_Jv_MonitorLock etc are compiled in by default (since we build with -g 
by default?). It might be worth changing them to JvAsserts so they only 
get compiled in with --enable-libgcj-debug.

>The synchronized factorial test may also be a little pessimistic w.r.t. the
>effect of hash synchronization.  I suspect a big part of the win is the fact
>that you typically don't need to allocate a lock structure in order to
>synchronize on an object.  This benchmark seems to only synchronize on one
>object, so that doesn't really matter.  My impression is that most real code
>tends to do lots of spurious synchronization on many different objects, e.g.
>StringBuffers, often with a small number of synchronizations on each object.
>

I've often wondered if it wouldn't be better to teach the compiler about 
compare-and-swap, and inline the lightweight part of 
_Jv_MonitorEnter/Exit. The inlined code would only call out to an 
external function in the unlikely event of a heavy lock or contention. 
Of course, this would probibly mean ditching the reduced-memory benefits 
of the hashtable, but I'm not convinced that would be a big loss given 
the 64-bit alignment requirements. I think this could be a big win 
particularly on platforms that have a convenient thread register.

regards

Bryce.