Java value layout constants
John Rose
john.r.rose at oracle.com
Tue Nov 30 19:22:10 UTC 2021
On Nov 30, 2021, at 5:05 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>> wrote:
In order to have reliable alignment checks which work on both native and heap segments, our API should assume that memory addresses produced by an heap segments can never be more aligned than the element size of the Java array backing that heap segment. This means that if we have a segment backed by a short[], the *maximum alignment* constraint supported by this segment is, for instance, 2. If we try to store an aligned int inside this segment, an error should occur (whether the store occur as a result of dereference, or bulk-copy), as there is no guarantee that this operation is well-defined across all platforms. Conversely, a native segment has _no_ maximum alignment.
Yes, this is the key new move. It hides (“abstracts away”) any alignment
that any particular position in a byte array might have, relative to a
storage unit larger than a byte. It hides any alignment stronger than
16-bit alignment at every position in a char array, even if (physically
speaking) some positions in a char array *are* in fact more aligned
than others.
I think one net effect of this is to push users away from byte arrays
and towards long arrays, if they choose to use aligned layouts with
mixed types. You can push and pull aligned bytes (and ints and shorts)
into a long array, but you can’t push and pull aligned longs into a
byte array, under these new rules, no matter how clever you are
about picking the offset into the byte array.
Of course, you can *always* push and pull *unaligned* values of
any layout into any primitive array. There’s always a (native order)
byte-wise view of any such array.
If you want a mix of aligned and unaligned accesses, then use a
long array for backing store.
This scales up to post-64-bit types such as aligned vectors. You
need a backing store with hyper-alignment, and the segment
holding such a hyper-aligned array (of some invisible type like
uint128_t) would allow aligned accesses up to 128 bits but no
further, even if the user were “lucky” in picking an offset that
was more physically aligned.
(We could consider abstracting away from native order, pretending
that the JVM makes a hidden private decision about byte order for
each array. In that case both alignment and size would have to match
exactly for such an array. That seems to be too much abstraction.)
More information about the panama-dev
mailing list