Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed

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

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
142c585
8315131: Clarify VarHandle set/get access on 32-bit platforms
liach Jul 10, 2025
1550fcc
Correct term is atomic, not word tearing
liach Jul 11, 2025
7563e6b
"may be non-atomic"
liach Jul 11, 2025
3235899
avoid "non-atomic"
liach Jul 17, 2025
8e702d2
Simplify wording
liach Jul 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -278,7 +278,7 @@
* <ul>
* <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}.
* are supported but may be non-atomic, as described in Section {@jls 17.7}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this is relevant, but isn't "opaque" access the way to request atomicity "by all means possible"? So a user who cares can use VH::getOpaque if the requirement is atomicity aligned to CAS.

I still agree that it is good to specify the meaning of plain VH::get and VH::set as much as possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opaque mode indeed ensures atomic access to primitive and reference variables.
In addition, it ensures coherence on that variable.

* of <cite>The Java Language Specification</cite>.
* <li>atomic update access modes for {@code int}, {@code long},
* {@code float}, {@code double} and {@link MemorySegment}.
Expand Down
7 changes: 4 additions & 3 deletions src/java.base/share/classes/java/lang/invoke/MethodHandles.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4305,9 +4305,10 @@ public static VarHandle byteArrayViewVarHandle(Class<?> viewArrayClass,
* If access is aligned then following access modes are supported and are
* guaranteed to support atomic access:
* <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.
* <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} are supported but may be non-atomic, as described in Section
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

* {@jls 17.7} of <cite>The Java Language Specification</cite>.
* <li>atomic update access modes for {@code int}, {@code long},
* {@code float} or {@code double}.
* (Future major platform releases of the JDK may support additional
Expand Down