This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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@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.
>
>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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]