Summary
-------
Update the specification of `java.lang.invoke.MethodHandles::byteBufferViewVarHandle` to clarify a potential misconception, and update `java.lang.foreign.MemoryLayout` specification to correct a mistake.
Problem
-------
The description about aligned access for `byteBufferViewVarHandle` sounds like `get` and `set` access modes for `long` and `double` are not supported on 32-bit platforms. In reality, they are supported, but they can be non-atomic or atomic. Related documentation on `MemoryLayout` claims the problem is "word tearing", but in reality, it is non-atomic treatment of long and/or double.
- Word tearing: More than one variables stored in one synchronization unit (word), where when updating one, the other parts of a subword region is assumed unchanged and so an update potentially overwrites changes onto other variables incorrectly
- Non-atomic treatment of long/double: inconsistency across two words/synchronization units because you cannot synchronize them together, so reads and writes are split, and you can read a nonexistent value composed of two unrelated writes
In addition, the term "atomic"/"non-atomic" is confusing in this context: they can refer to memory access (read, write), or the whole encapsulated VH operation (CAS, CAE, etc.). We need better wording to describe the memory access without any VH operation implications.
Solution
--------
Fix the specification found in `java.lang.foreign.MemoryLayout` to state "no atomicity guarantee" instead of using "word tearing". Slightly tweak it as we do not support the `MemorySegment` type, and reuse this to `byteBufferViewVarHandle`.
Specification
-------------
```
diff --git a/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java b/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
index cb51bbaf795b0..f55deba6e7fac 100644
--- a/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
+++ b/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
@@ -276,10 +276,10 @@
* if {@code A >= S}. An aligned var handle is guaranteed to support the following
* access modes:
* <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}.
- * of <cite>The Java Language Specification</cite>.
+ * <li>read write access modes for all {@code T}. Access modes {@code get} and
+ * {@code set} for {@code long}, {@code double} and {@code MemorySegment}
+ * are supported but have no atomicity guarantee, as described in Section
+ * {@jls 17.7} of <cite>The Java Language Specification</cite>.
* <li>atomic update access modes for {@code int}, {@code long},
* {@code float}, {@code double} and {@link MemorySegment}.
* (Future major platform releases of the JDK may support additional
diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
index 3d7ba22e54e09..b0f7a53ea713a 100644
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
@@ -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}. Access modes {@code get}
+ * and {@code set} for {@code long} and {@code double} are supported but
+ * have no atomicity guarantee, as described in 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
```