Re: Alpha vs. new ABI

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> 1) I don't have measurements, but my intuition is that extra
Hans> padding will hurt performance measurably.

What about the case where we use the same alignment for the `data'
element for all types (but only up to the maximal alignment required
by Java types)?  Then extra padding will only occur for types that
don't already have Java-maximal alignment, eg `byte'.  Do you think
this will matter?

Hans> 2) The offsets change with my hash synchronization patch.  A
Hans> pointer field disappears from the array header (and from every
Hans> other object).

So we need to find a solution that is robust in the face of this
change.

With your patch we'll have just the vtable slot (a pointer) and the
array length slot (a 32-bit int).  On x86 this means we'll never need
any padding.  On alpha we'll still need 4 bytes padding for doubles.

Hans> 3) I don't think I understand the reason for the alignment
Hans> requirement here.

The data for an array has to be aligned (at least) according to its
type.  Right now in some scenarios the compiler and the runtime
disagree about this alignment, resulting in chaos.  For instance,
right now this causes `hello, world' to fail on the alpha, because
there are an extra 4 bytes of padding that the runtime doesn't expect.


I still prefer the solution of minimizing space wastage and giving the
`data' member natural alignment for its type.  However I'm amenable to
any solution that actually works, especially given that we don't have
hard data on the tradeoffs involved.  We're going to break binary
compatibility any number of times.  If we make a bad choice here, we
can change it.

Tom