Alignment problem with hashtable locks on PowerPC

[Bryce McKinlay]

Boehm, Hans wrote:

>You're talking about adding a sync_info word back to the objects, so that
>the inlined code wouldn't have to do he hash function computation, etc.?  I
>think the current code is probably slightly too big to be inlined, even if
>the thread id is in a register.  (Having that as a non-default compiler
>option might be interesting, though.)
>

Yes.

>That's an interesting trade-off, and one I'd like to understand better.  It
>would make gcj's synchronization cost very similar to everyone elses.  But I
>think it does cost elsewhere.
>
>On most platforms, at least doubles need
>to be aligned anyway, which means that you either need to have objects
>containing doubles allocated differently, or you need 64-bit alignment
>everywhere.  (Does PowerPC really not require that?  Itanium equires 16 byte
>alignment for malloc, since some loads and stores require 16-byte alignment.
>

I am told that PowerPC has no requirement for alignment greater than 4 
bytes (except for Altivec vectors which must be 16-byte aligned). Of 
course, aligning doubles to 8-bytes is probibly a good idea for 
performance. The Mac OS X ABI says that doubles are 8-byte aligned on 
the stack but not neccessarily when packed in structs.

>My intuition would be to favor object size over synchronization cost, since
>it's usually possible, though admittedly hard, for the programmer and/or
>compiler to eliminate the synchronization when it turns into a real problem.
>But measurements would be really nice.
>

Good point. We really need some large benchmarks that are closer to 
simulating real world application conditions than the numerical 
benchmarks and simple tests that I usually run.

I do think its usually possible (and good practise) to eliminate 
synchronization wherever its not needed. But there is at least one very 
common case where automatic elimination probibly isn't possible and the 
programmer has no choice in the matter: AWT.

regards

Bryce.