8315131: Clarify VarHandle set/get access on 32-bit platforms

[liach]

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

jdk/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java

Lines 279 to 282 in ee0d309

	* <li>read write access modes for all {@code T}. On 32-bit platforms, access modes
	* {@code get} and {@code set} for {@code long}, {@code double} and {@code MemorySegment}
	* are supported but might lead to word tearing, as described in Section {@jls 17.7}.
	* of <cite>The Java Language Specification</cite>.

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

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires CSR request JDK-8361935 to be approved

Issues

• JDK-8315131: Clarify VarHandle set/get access on 32-bit platforms (Bug - P4)
• JDK-8361935: Clarify VarHandle set/get access on 32-bit platforms (CSR)

Reviewers

• Aleksey Shipilev (@shipilev - Reviewer) Review applies to 1550fcc0
• Raffaello Giulietti (@rgiulietti - Reviewer)
• Paul Sandoz (@PaulSandoz - Reviewer) Review applies to 7563e6b7
• Maurizio Cimadamore (@mcimadamore - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26258/head:pull/26258
$ git checkout pull/26258

Update a local copy of the PR:
$ git checkout pull/26258
$ git pull https://git.openjdk.org/jdk.git pull/26258/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26258

View PR using the GUI difftool:
$ git pr show -t 26258

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26258.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back liach! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@liach This change is no longer ready for integration - check the PR body for details.

[openjdk]

@liach The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 04: Full - Incremental (8e702d27)
• 03: Full - Incremental (3235899a)
• 02: Full - Incremental (7563e6b7)
• 01: Full - Incremental (1550fcc0)
• 00: Full (142c5855)

[shipilev]

I think it looks okay. But I am not spec expert, you need someone else to look at this carefully.

[rgiulietti]

To be super-pedantic, JLS 17.7 does not guarantee atomic access of longs and doubles, not even on 64-bit platforms. It only encourages implementations to do so if possible.
But I think we can safely assume that quality 64-bit implementations will indeed provide atomic access of longs and doubles.

[PaulSandoz]

Pedantically it is "... but are not guaranteed to be atomic, ...", since IIUC some 32-bit CPU architectures support 64-bit loads and stores (e.g., the ARM A32 LDREXD instruction) so the JVM can do something stronger than what is prescribed by the JMM.

[liach]

Thanks, updated to be "but may be non-atomic". Please review the CSR as well.

[liach]

You are right. I should use "may be non-atomic", as the implementation can make these operations atomic.

Also re JLS 17.7 for 64-bit platforms: this phrase is qualified to be on 32-bit platforms, and we are already under aligned access, so I assume we have sufficient preconditions to ignore this aspect.

[liach]

I think @mcimadamore and @JornVernee still disagree with this - they think "atomic" can mean a CAS operation as a whole is atomic, or an individual memory access (read, write) in the CAS is. This atomicity here is lacking for the individual memory access, which is the weaker form of atomicity.

On another look, I think another way to address this problem could be to move this "potential lack of atomicity in memory access" to "get" and "set" themselves - which also applies to unaligned access and other var handles. Then, for aligned access through VH, the VH just specify it implements all access modes and upholds all atomicity guarantees of those modes (with respect to other threads)

[rgiulietti]

Suggested change

	* are supported but may be non-atomic, as described in Section {@jls 17.7}
	* are supported but may be non-atomic in the sense of Section {@jls 17.7}

A useful taxonomy has atomic read-modify-write operations (atomic updates, numeric atomic updates, bitwise atomic updates, like CASes, etc.), and atomic access operations, that is, atomic loads and stores (atomic reads and writes).

But the reference to the JLS section here should clarify what is meant in this specific context, namely access operation, not read-modify-write operations.

[liach]

Yep, to distinguish access and the encapsulated read-modify-write atomicity, I decided to avoid using "atomic"/"non-atomic" altogether - now it is just "make no atomicity guarantee"

[rgiulietti]

Suggested change

	* double} are supported but may be non-atomic, as described in Section
	* double} are supported but may be non-atomic in the sense of Section

[mcimadamore]

Looks good, thanks!

[rgiulietti]

Looks good