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

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

[Billinghurst, David (CRTS)]

cygwin readers:  This is about porting java to cygwin for gcc-3.2
(and perhaps gcc-3.1.1 if the changes are small).

So we need objects to be 8-byte aligned so that the low three bits
of the address are 0?  Are there any ways around this, as I don't 
think that this is the default on cygwin.  

I seem to recall that:
 - objects are only 4-byte aligned by default.  
 - it is necessary to rebuild ld to ensure 8-byte alignment
 - there are performance benefits for 8-byte (or even 16-byte)
   alignment, but arguements against.

There is much discussion over a long period in the cygwin archives,
which I will obviously have to re-read in the next little while.

-----Original Message-----
From: Tom Tromey [mailto:tromey@redhat.com]
Sent: Saturday, 4 May 2002 6:31 
To: Billinghurst, David (CRTS)
Cc: java@gcc.gnu.org
Subject: Re: cygwin failures - assertion "!(addr & FLAGS)" failed:


>>>>> "David" == Billinghurst, David (CRTS) <David.Billinghurst@riotinto.com> writes:

David> At last a real bug in the cygwin libjava testsuite.  Most of the 
David> compilation tests pass, but all (that I could find) executable 
David> tests fail with 

David> assertion "!(addr & FLAGS)" failed: file "/usr/local/src/gcc3.1/libjava/java/lang/natObject.cc", line 772

My understanding is that we use the lowest 3 bits to keep some
information about the thin locks.  If this assertion fails, it means
that we've found an object which isn't suitably aligned.  I think this
can mean one of two things:

1. There is a bug in the allocator (unlikely), or
2. The compiler isn't properly aligning an object which it lays out
   statically.  For instance this could happen with some Class object

A bug along these lines was fixed pretty recently:

2002-04-18  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>

	* class.c (make_class_data): Set DECL_ALIGN on static class data,
	for hash synchronization.
	* expr.c (java_expand_expr): Set DECL_ALIGN on static array objects.
	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN for
	class_type_node.

If you already have this patch then I guess there's another such bug :-(

Tom

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

[Tom Tromey]

>>>>> "David" == Billinghurst, David (CRTS) <David.Billinghurst@riotinto.com> writes:

David> So we need objects to be 8-byte aligned so that the low three
David> bits of the address are 0?  Are there any ways around this, as
David> I don't think that this is the default on cygwin.

For libgcj this decision is made either by the GC (for dynamically
allocated objects) or the compiler (for statically allocated objects).

The GC should already be doing this.

The compiler might not, but that is something that, in theory, we can
fix entirely in gcj by setting the required alignment correctly.
Unless...

David>  - it is necessary to rebuild ld to ensure 8-byte alignment

... there is some problem getting ld to do this even when gcj sets the
alignment correctly on the type.

It looks like the alignment is in fact set correctly in gcj:

  /* Hash synchronization requires at least 64-bit alignment. */
  if (flag_hash_synchronization && POINTER_SIZE < 64)
    DECL_ALIGN (decl) = 64; 

Tom

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

[Tim Prince]

On Sunday 05 May 2002 16:49, Billinghurst, David (CRTS) wrote:
> cygwin readers:  This is about porting java to cygwin for gcc-3.2
> (and perhaps gcc-3.1.1 if the changes are small).
>
> So we need objects to be 8-byte aligned so that the low three bits
> of the address are 0?  Are there any ways around this, as I don't
> think that this is the default on cygwin.
>
> I seem to recall that:
>  - objects are only 4-byte aligned by default.
The binutils alignment parameter in coff-i386.c is set to 4-byte alignment.  
4-byte alignment also is the default for gcc -Os, at least from gcc-3.1.  
Cases have been produced where gcc-3.1 failed to give 16-byte alignment 
even with -O2, unless -mpreferred-stack-boundary=4 was specified.
>  - it is necessary to rebuild ld to ensure 8-byte alignment
not only ld, but all of binutils
>  - there are performance benefits for 8-byte (or even 16-byte)
>    alignment, but arguements against.
8-byte alignment is required for reasonable performance with 64-bit data.  
16-byte alignment is required by <xmmintrin.h>, which uses aligned sse 
instructions, and for reasonable performance with un-aligned sse instructions.
P4 does not share the 16-byte code alignment requirements for full 
performance which P-II/P-III have.

I have been building and testing gcc-3.1 in cygwin with 16-byte alignments 
specified, wherever I know how, with no ill effects, and I consider it a must 
for gcc-3.1.
16-byte alignment is incompatible AFAIK with the libstdc++ of gcc-2.95.x, but 
the C, f77, and objc compilers have no problem with it.
The primary argument I have seen for making 4-byte alignment the default for 
-Os in gcc had to do with the 1MB stack per thread limitation being easily 
exceeded.  Future glibc should always have at least 8MB stack per thread.  I 
don't know the answers for the cygwin environment.
Another argument which has been made in the past is that MSVC couldn't be 
counted upon for better than 4-byte alignments.
>
> There is much discussion over a long period in the cygwin archives,
> which I will obviously have to re-read in the next little while.
>
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Saturday, 4 May 2002 6:31
> To: Billinghurst, David (CRTS)
> Cc: java@gcc.gnu.org
>
> Subject: Re: cygwin failures - assertion "!(addr & FLAGS)" failed:
> >>>>> "David" == Billinghurst, David (CRTS)
> >>>>> <David.Billinghurst@riotinto.com> writes:
>
> David> At last a real bug in the cygwin libjava testsuite.  Most of the
> David> compilation tests pass, but all (that I could find) executable
> David> tests fail with
>
> David> assertion "!(addr & FLAGS)" failed: file
> "/usr/local/src/gcc3.1/libjava/java/lang/natObject.cc", line 772
>
> My understanding is that we use the lowest 3 bits to keep some
> information about the thin locks.  If this assertion fails, it means
> that we've found an object which isn't suitably aligned.  I think this
> can mean one of two things:
>
> 1. There is a bug in the allocator (unlikely), or
> 2. The compiler isn't properly aligning an object which it lays out
>    statically.  For instance this could happen with some Class object
>
> A bug along these lines was fixed pretty recently:
>
> 2002-04-18  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>
>
> 	* class.c (make_class_data): Set DECL_ALIGN on static class data,
> 	for hash synchronization.
> 	* expr.c (java_expand_expr): Set DECL_ALIGN on static array objects.
> 	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN for
> 	class_type_node.
>
> If you already have this patch then I guess there's another such bug :-(
>
> Tom

-- 
Tim Prince

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

[Tom Tromey]

>>>>> "Tim" == Tim Prince <tprince@computer.org> writes:

Tim> The binutils alignment parameter in coff-i386.c is set to 4-byte
Tim> alignment.  4-byte alignment also is the default for gcc -Os, at
Tim> least from gcc-3.1.  Cases have been produced where gcc-3.1
Tim> failed to give 16-byte alignment even with -O2, unless
Tim> -mpreferred-stack-boundary=4 was specified.

Are you talking about only the alignment of the stack?  I don't think
that should matter to libgcj.  There used to be one place where we
stack-allocated an object, but I believe that now there aren't any.
All that matters to us is the alignment of statically allocated
object, and objects created by the GC.

Tom

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

[Tim Prince]

On Sunday 05 May 2002 21:49, Tom Tromey wrote:
> >>>>> "Tim" == Tim Prince <tprince@computer.org> writes:
>
> Tim> The binutils alignment parameter in coff-i386.c is set to 4-byte
> Tim> alignment.  4-byte alignment also is the default for gcc -Os, at
> Tim> least from gcc-3.1.  Cases have been produced where gcc-3.1
> Tim> failed to give 16-byte alignment even with -O2, unless
> Tim> -mpreferred-stack-boundary=4 was specified.
>
> Are you talking about only the alignment of the stack?  I don't think
> that should matter to libgcj.  There used to be one place where we
> stack-allocated an object, but I believe that now there aren't any.
> All that matters to us is the alignment of statically allocated
> object, and objects created by the GC.
>
> Tom
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. Static objects are under the control of the alignment for which 
binutils is built, so you don't get 8-byte alignment of statics with the 
stock cygwin binutils build.
-- 
Tim Prince

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

[Billinghurst, David (CRTS)]

I will potter along with a modified binutils for a while.  IF I get
something workable THEN we can try and identify the best fix for each 
of the issues that have been identified.

-----Original Message-----
From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
Sent: Wednesday, 8 May 2002 11:30 
To: Billinghurst, David (CRTS)
Cc: java@gcc.gnu.org; cygwin@cygwin.com
Subject: Re: Object alignment, was: cygwin failures - assertion "!(addr
&FLAGS)" failed:


Billinghurst, David (CRTS) wrote:

>After rebuilding binutils with 16-byte alignment
> - the first libjava testsuite executable ran
> - another dejagnu problem killed the testsuite 
>
>So this approach is promising, but will need to do some
>more dejagnu hacking :-< 
>  
>

So the problem is that binutils doesn't/can't support alignment 
directives (.align) for win32 targets? If this is the case it would 
probibly be better to tweak libjava/configure.in so that hash 
synchronization is disabled for win32. AFAIK thats the only thing in 
libgcj that has the 8-byte alignment requirement.

regards

Bryce.

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

[Bryce McKinlay]

Billinghurst, David (CRTS) wrote:

>After rebuilding binutils with 16-byte alignment
> - the first libjava testsuite executable ran
> - another dejagnu problem killed the testsuite 
>
>So this approach is promising, but will need to do some
>more dejagnu hacking :-< 
>  
>

So the problem is that binutils doesn't/can't support alignment 
directives (.align) for win32 targets? If this is the case it would 
probibly be better to tweak libjava/configure.in so that hash 
synchronization is disabled for win32. AFAIK thats the only thing in 
libgcj that has the 8-byte alignment requirement.

regards

Bryce.

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

[Billinghurst, David (CRTS)]

After rebuilding binutils with 16-byte alignment
 - the first libjava testsuite executable ran
 - another dejagnu problem killed the testsuite 

So this approach is promising, but will need to do some
more dejagnu hacking :-< 


-----Original Message-----
From: Tom Tromey [mailto:tromey@redhat.com]
Sent: Monday, 6 May 2002 10:24 
To: Billinghurst, David (CRTS)
Cc: java@gcc.gnu.org; cygwin@cygwin.com
Subject: Re: Object alignment, was: cygwin failures - assertion "!(addr
& FLAGS)" failed:


>>>>> "David" == Billinghurst, David (CRTS) <David.Billinghurst@riotinto.com> writes:

David> So we need objects to be 8-byte aligned so that the low three
David> bits of the address are 0?  Are there any ways around this, as
David> I don't think that this is the default on cygwin.

For libgcj this decision is made either by the GC (for dynamically
allocated objects) or the compiler (for statically allocated objects).

The GC should already be doing this.

The compiler might not, but that is something that, in theory, we can
fix entirely in gcj by setting the required alignment correctly.
Unless...

David>  - it is necessary to rebuild ld to ensure 8-byte alignment

... there is some problem getting ld to do this even when gcj sets the
alignment correctly on the type.

It looks like the alignment is in fact set correctly in gcj:

  /* Hash synchronization requires at least 64-bit alignment. */
  if (flag_hash_synchronization && POINTER_SIZE < 64)
    DECL_ALIGN (decl) = 64; 

Tom

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

[Boehm, Hans]

> From: Randall R Schulz [mailto:rrschulz@cris.com]
> 
> 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?
Not that I know of.  I think it would be fairly easy to make this
configurable.  The code shouldn't rely on the position of those bits anyway,
and I believe it doesn't.

This may help with some embedded applications.  Otherwise I'm not sure it
would buy you much.  On 64-bit processore, 8-byte alignment is generally
required anyway.  On 32-bit processors, I don't think you want to limit the
address space any more than it already is.

My guess is that allowing the code to be configured to require only 8 byte
object spacing (by simply dropping the low order bits in the locking code)
is a more general solution.

Hans

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

[Tom Tromey]

>>>>> "Randall" == Randall R Schulz <rrschulz@cris.com> writes:

Randall> Is stack-based object allocation really feasible for Java
Randall> outside of some very narrow special cases (i.e., when the
Randall> reference to the instance can be proved never to propagate
Randall> outside the method in which it's created)?

Only if you do whole program analysis.  See the IBM Jalapeno paper on
escape analysis for the details.  I suppose it is possible that the
special cases are still interesting.

I doubt gcj will have stack allocation any time soon.  As far as I
know nobody is working on it.  And my guess is there are easier ways
to get performance boosts, for instance type-based optimization on the
trees.

Tom

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

[Randall R Schulz]

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

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

[Boehm, Hans]

> 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