On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang <li...@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:
> 
>   Correct term is atomic, not word tearing

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:

> 279:  * <li>read write access modes for all {@code T}. On 32-bit platforms, 
> access modes
> 280:  *     {@code get} and {@code set} for {@code long}, {@code double} and 
> {@code MemorySegment}
> 281:  *     are supported but not atomic, as described in Section {@jls 17.7}

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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2201432837

Reply via email to