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: <5.1.0.14.2.20020506133047.00b04ea8@pop3.cris.com>
X-Sender: rrschulz AT pop3 DOT cris DOT com
Date: Mon, 06 May 2002 13:40:13 -0700
To: "Boehm, Hans" <hans_boehm AT hp DOT com>,
   "'tprince AT computer DOT org'" <tprince AT computer DOT org>, tromey AT redhat DOT com
From: Randall R Schulz <rrschulz AT cris DOT com>
Subject: RE: Object alignment, was: cygwin failures - assertion "!(addr
  &  FLAGS)" failed:
Cc: "Billinghurst, David (CRTS)" <David DOT Billinghurst AT riotinto DOT com>,
   java AT gcc DOT gnu DOT org, cygwin AT cygwin DOT com
In-Reply-To: <40700B4C02ABD5119F000090278766443BF292@hplex1.hpl.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hans,

Is there a reason that the three bits used for lock management must be the 
least significant three? The XSB interpreter (XSB is a Prolog system) uses 
even more bits, but doesn't demand that they be contiguous. Depending on 
the processor, machine and OS architecture, the tag bits XSB needs (which 
are classic data type tags) can be split and reassembled as needed. 
Naturally, it can get costly to do this, but I assume that it maximizes the 
set of systems on which XSB can run while preserving as many bits as 
possible for the actual (type-tagged) data values stored.

Is there a reason a more flexible approach to "stolen" bits cannot be taken 
by GCJ?

By the way, how would any Java get away with instance (not reference) 
allocation on the stack? Does it not require global data flow analysis to 
accurately determine the lifetime of Java instances? At least I think it 
does for instances whose references get passed to another method, stored in 
a field or returned from the instantiating method. Is stack-based object 
allocation really feasible for Java outside of some very narrow special 
cases (i.e., when the reference to the instance can be proved never to 
propagate outside the method in which it's created)?

Randall Schulz
Mountain View, CA uSA


At 10:57 2002-05-06, Boehm, Hans wrote:
> > 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/