On Fri, 11 Jul 2025 08:19:43 GMT, Aleksey Shipilev <sh...@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 > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4311: > >> 4309: * access modes {@code get} and {@code set} for {@code long}, >> {@code >> 4310: * double} are supported but might lead to word tearing, as >> described in >> 4311: * Section {@jls 17.7} of <cite>The Java Language >> Specification</cite>. > > ...except that JLS 17.7 is "Non-Atomic Treatment of double and long". Word > tearing (JLS 17.6) should still be very much forbidden. This all means that > [MemoryLayout.java](https://github.com/openjdk/jdk/blob/ee0d309bbd33302d8c6f35155e975db77aaea785/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java#L279-L282) > comment is also incorrect. > > Note how the previous paragraph talks about "support atomic access", which is > a correct term here. Right, "word tearing" and "non-atomic access" are different notions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2200683349