[foreign-memaccess+abi] RFR: 8315096: Allowed access modes in memory segment should depend on layout alignment

[Paul Sandoz]

On Mon, 28 Aug 2023 11:47:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There are some issues with the way memory segment var handle are specified and implemented: if an access mode is not supported, then using such access mode should result in an `UnsupportedOperationException`. But in our implementation, all alignment issues result in `IllegalArgumentException`.
> 
> This means that clients can get the same exception if:
> 
> * they try to read a 4-byte aligned int at a physical address that is not multiple of 4 (use-site error, IAE is good)
> * they try to do a compareAndSwap on a var handle obtained using an unaligned int layout (decl-site error, IAE is not good, and UOE should be used instead).
> 
> This PR rectifies this issue: now a var handle is either *aligned* (meaning it is constructed with a value layout which respects the *size* of the accessed carrier type), or *unaligned*. Aligned var handles enjoy more access modes. Unaligned var handle only support `get`/`set`. Trying to use any other access mode on an unaligned var handle will now result in `UOE` regardless of the address being accessed - which makes the code more robust and portable.
> 
> This PR also clarifies the javadoc, by avoiding using the term "atomic access" to mean "absence of tearing". This is confusing because we then refer to terms such as "atomic updates" also to refer to operations such as CAS.
> 
> The proposed javadoc now uses the term "Word Tearing" which is taken from the memory model section of the JLS (and even has a link to it).

Looks good.

I notice a subtle difference between this VH behavior and that for arrays and `ByteBuffer`, as specified by the methods on `MethodHandles`, which state:

     * <ul>
     * <li>read write access modes for all {@code T}, with the exception of
     *     access modes {@code get} and {@code set} for {@code long} and
     *     {@code double} on 32-bit platforms.

I don't exactly recall why we restricted on 32-bit platforms, but it might have been because of some `Unsafe` restriction/complexity in supporting the atomicity that is required for volatile (or more generally non-plain) access (e.g., see https://shipilev.net/blog/2014/all-accesses-are-atomic/#_implementation_specifics). So we probably said well we won't support it at all, but i doubt we assert on that given 32-bit is not a system we generally focus on.

-------------

PR Review: https://git.openjdk.org/panama-foreign/pull/876#pullrequestreview-1598715287