RE: Alpha vs. new ABI

["Boehm, Hans" <hans_boehm at hp dot com>]

> From: Tom Tromey [mailto:tromey@redhat.com]
> 
> 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?
Probably it still matters matters a bit.  Presumably Java-maximal alignment
should really be 8 on most platforms?  I would guess that small char (e.g.
in StringBuffer), int, and float arrays are fairly frequent.  Even if they
have short lifetimes, they increase GC frequency.

This is probably not a huge issue, but I don't have a feeling for how easy
it is to avoid. 
> 
> 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.
And we can generalize that to most 32- and 64-bit platforms respectively, I
think.  But I'm not sure we will want to enable hash synchronization on all
platforms.
> 
> 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.
> 
Sounds right to me.

Hans