Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <40700B4C02ABD5119F000090278766443BF292@hplex1.hpl.hp.com>
From: "Boehm, Hans" <hans_boehm AT hp DOT com>
To: "'tprince AT computer DOT org'" <tprince AT computer DOT org>, tromey AT redhat DOT com
Cc: "Billinghurst, David (CRTS)" <David DOT Billinghurst AT riotinto DOT com>,
   java AT gcc DOT gnu DOT org, cygwin AT cygwin DOT com
Subject: RE: Object alignment, was: cygwin failures - assertion "!(addr & 
	FLAGS)" failed:
Date: Mon, 6 May 2002 10:57:38 -0700 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> From: Tim Prince [mailto:tprince AT computer DOT 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.

Hans

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/