On Wed, 13 May 2026 14:17:21 GMT, Frederic Parain <[email protected]> wrote:
>> src/hotspot/share/opto/inlinetypenode.cpp line 2228: >> >>> 2226: // in size and would then be written by a "normal" oop store. If >>> the payload contains oops, its size is always >>> 2227: // 64-bit because the next smaller (power-of-two) size would be >>> 32-bit which could only hold one narrow oop that >>> 2228: // would then be written by a normal narrow oop store. These >>> properties are asserted in 'convert_to_payload'. >> >> I was a little surprised that this is hard-coded to 64-bit, when x64 and >> aarch64 can do 128-bit atomic reads and writes. But maybe the problem is >> that GPRs are 64 bit, so a 128-bit memory op would require a register pair >> or vector register? > > 128 bits atomic ops require a 16 bytes alignment, but objects in the Java > heap currently only have a 8 bytes alignment guarantee. For this reason, > flattening of atomic values is limited to 64 bits in this first > implementation of JEP 401. Increasing flattening limit to 128 bits for atomic > values might be possible in the future but it would require significant work > in the GC, runtime and JIT areas. (resolved) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3320966967
