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

[Maurizio Cimadamore]

On Tue, 29 Aug 2023 01:34:58 GMT, ExE Boss <duke 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).
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 182:
> 
>> 180:                           SCOPED_MEMORY_ACCESS.get$RawType$Volatile(bb.sessionImpl(),
>> 181:                                   bb.unsafeGetBase(),
>> 182:                                    offsetNonPlain(bb, base, handle.alignmentMask)));
> 
> The `offsetNonPlain` calls have an extra space:
> Suggestion:
> 
>                                   offsetNonPlain(bb, base, handle.alignmentMask)));
> 
> 
> (this would’ve been avoidable if JDK used the more accessible tabs[^1] for indentation)
> 
> [^1]: prettier/prettier#7475

> The `offsetNonPlain` calls have an extra space:
> 
> (this would’ve been avoidable if JDK used the more accessible tabs[1](#user-content-fn-1-a99cebfdb5a6913c73e9a68c7c0e7c46) for indentation)
> ## Footnotes
> 
>     1. [Change `useTabs` to `true` by default prettier/prettier#7475](https://github.com/prettier/prettier/issues/7475) [↩](#user-content-fnref-1-a99cebfdb5a6913c73e9a68c7c0e7c46)

Part of the issue here is that this file is a template - so it's not a ".java" file, and as such, the IDE doesn't help with this stuff.

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

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/876#discussion_r1308433753