public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* RE: Object alignment, was: cygwin failures - assertion "!(addr &  FLAGS)" failed:
@ 2002-05-06 10:57 Boehm, Hans
  2002-05-06 13:39 ` Randall R Schulz
  0 siblings, 1 reply; 11+ messages in thread
From: Boehm, Hans @ 2002-05-06 10:57 UTC (permalink / raw)
  To: 'tprince@computer.org', tromey
  Cc: Billinghurst, David (CRTS), java, cygwin

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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: Object alignment, was: cygwin failures - assertion "!(addr &FLAGS)" failed:
@ 2002-05-07 19:31 Billinghurst, David (CRTS)
  0 siblings, 0 replies; 11+ messages in thread
From: Billinghurst, David (CRTS) @ 2002-05-07 19:31 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: java, cygwin

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.



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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed:
@ 2002-05-07 17:19 Billinghurst, David (CRTS)
  2002-05-07 19:21 ` Bryce McKinlay
  0 siblings, 1 reply; 11+ messages in thread
From: Billinghurst, David (CRTS) @ 2002-05-07 17:19 UTC (permalink / raw)
  To: java, cygwin

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

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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: Object alignment, was: cygwin failures - assertion "!(addr &  FLAGS)" failed:
@ 2002-05-06 14:50 Boehm, Hans
  0 siblings, 0 replies; 11+ messages in thread
From: Boehm, Hans @ 2002-05-06 14:50 UTC (permalink / raw)
  To: 'Randall R Schulz',
	Boehm, Hans, 'tprince@computer.org',
	tromey
  Cc: Billinghurst, David (CRTS), java, cygwin

> 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

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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed:
@ 2002-05-05 16:51 Billinghurst, David (CRTS)
  2002-05-05 17:14 ` Tom Tromey
  2002-05-05 17:23 ` Tim Prince
  0 siblings, 2 replies; 11+ messages in thread
From: Billinghurst, David (CRTS) @ 2002-05-05 16:51 UTC (permalink / raw)
  To: java; +Cc: cygwin

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

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2002-05-08  2:21 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-05-06 10:57 Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed: Boehm, Hans
2002-05-06 13:39 ` Randall R Schulz
  -- strict thread matches above, loose matches on Subject: below --
2002-05-07 19:31 Object alignment, was: cygwin failures - assertion "!(addr &FLAGS)" failed: Billinghurst, David (CRTS)
2002-05-07 17:19 Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed: Billinghurst, David (CRTS)
2002-05-07 19:21 ` Bryce McKinlay
2002-05-06 14:50 Boehm, Hans
2002-05-05 16:51 Billinghurst, David (CRTS)
2002-05-05 17:14 ` Tom Tromey
2002-05-05 17:23 ` Tim Prince
2002-05-05 21:40   ` Tom Tromey
2002-05-05 23:44     ` Tim Prince

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).