Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed:

Boehm, Hans hans_boehm@hp.com
Mon May 6 10:57:00 GMT 2002

> From: Tim Prince [mailto:tprince@computer.org]
> Stack alignment matters when you use <xmmintrin.h>.  I didn't 
> take the 
> question as being one where gcj and libgcj were to be built 
> without regard to 
> other consequences, although I'm surprised if gcj doesn't 
> allocate anything 
> on stack.
To clarify a bit more:

The Java locking code needs to steal 3 bits from the address of Java objects
in order to be able to atomically update all the most important fields in a
"thin lock".  Thus it's critical that the least 3 significant bits in the
addresses of Java objects are not important.  Currently this is enforced by
insisting that all Java objects used for synchronization be 8-byte aligned.
We have talked about changing the code on some platforms so that the only
requirement becomes that 2 different object addresses used for
synchronization must be at least 8 bytes apart.  This change is a bit
tricky, but I don't think it's terribly expensive.  It may make sense to do
this for 3.2.

(It may also be possible to get by with 2 bits instead of 3.  But that
requires rethinking some very tricky code.)

AFAIK, Gcj currently does not try to turn heap allocations of Java objects
into stack allocations.  But if it did so (and ideally it should), we
probably still wouldn't need 8 byte stack alignment, since it's unlikely you
would be able to perform this optimization for objects that are shared
between threads.  Thus you should be able to replace any synchronization on
these objects by (at most) suitable memory barriers.


More information about the Java mailing list