Alpha vs. new ABI

Thu Feb 1 11:08:00 GMT 2001

> 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