RE: Alignment problem with hashtable locks on PowerPC

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

> From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
...
> I've heard that 
> pthread_self() is 
> pretty slow on ppc linux due to lack of provision for a 
> thread register 
> in the ABI, so that might have something to do with it - might be 
> interesting to try with SLOW_PTHREAD_SELF and see if it helps 
> things? 
I would definitely try that.  It cold make a substantial difference.  You
probably need to make a pass over that code to check that it's correct with
respect to the PowerPC memory model.

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.
Without hash synchronization all of those end up with pointer to newly
allocated sync_info structures.  But on X86 there seemed to be a clear
benefit even without repeated sync_info allocations.

You may also want to verify that is_mp() in natObject.cc does the right
thing.  Things will perform worse if it's confused about whether it's on a
multiprocessor.

It would be really nice if we had a better idea where it's spending its
time.  Maybe randomly interrupting it with gdb will provide a little
information?

Hans