RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms [v5]

[John R Rose]

On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> On 32 bit platforms, when an access to long/double is aligned, it is supported but not atomic. The original wording in `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at all. We can fix that by borrowing the improved specification from `MemoryLayout::varHandle`.
>> 
>> Note: This doc is copied from https://github.com/openjdk/jdk/blob/ee0d309bbd33302d8c6f35155e975db77aaea785/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java#L279-L282 with slight adjustments. See the rendering at https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html#access-mode-restrictions
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify wording

Marked as reviewed by jrose (Reviewer).

The previous comment is informational only.  I'm NOT suggesting the PR use the term "struct tearing", since that is not a term in the JVMS.  It's just a useful term that has cropped up in Project Valhalla as the generalization of long/double non-atomicity.  Another Valhalla term for the same thing, FWIW, is "loose consistency".  For technical discourse, either term is better than just "non-atomicity", since "non-atomicity" doesn't suggest there is any limit to the tearing; using bytewise memcpy on a long or a value object would be "non-atomic" but not "loosely consistent", so there is important daylight between the terms.

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

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3031277023
PR Comment: https://git.openjdk.org/jdk/pull/26258#issuecomment-3085811559