On Wed, 13 May 2026 04:07:30 GMT, Dean Long <[email protected]> wrote:
>> This is a "*sub-review pull request*" for the first >> [preview](https://openjdk.org/jeps/12) of [JEP 401: Value Classes and >> Objects](https://openjdk.org/jeps/401), specifically >> [JDK-8317278](https://bugs.openjdk.org/browse/JDK-8317278): JVM >> implementation of value classes and objects. >> >>> [!NOTE] >>> This pull request and the other sub-review pull requests listed below are >>> based on the "*master pull request*" >>> (https://github.com/openjdk/jdk/pull/31120). It contains the same full set >>> of code changes as the "*master pull request*" to preserve the full >>> implementation context; the language compiler, JVM, and standard library >>> changes are intertwined. This separate pull requests exist only to >>> subdivide the review and related discussion by area. >> >> Other areas for review: >> >> - [JDK-8317277](https://bugs.openjdk.org/browse/JDK-8317277): Java language >> implementation of value classes and objects >> - https://github.com/openjdk/jdk/pull/31121 >> - [JDK-8317279](https://bugs.openjdk.org/browse/JDK-8317279): Standard >> library implementation of value classes and objects >> - https://github.com/openjdk/jdk/pull/31123 >> >> Code changes resulting from the review process should be made in >> [`valhalla/lworld`](https://github.com/openjdk/valhalla/). >> >> `valhalla/lworld` is currently updated from `jdk/master` whenever a weekly >> [`jdk` tag](https://github.com/openjdk/jdk/tags) is created. At that time, >> code changes from `valhalla/lworld` will be propagated to the master pull >> request and to all sub-review pull requests, including this one. >> >> Ultimately, review sign-off will be recorded on the "*master pull request*", >> and this pull request will be closed without integration. >> >> This pull request has a large code surface area and often conflicts with >> `jdk/master` on a daily basis. Refer to >> [`valhalla/lworld`](https://github.com/openjdk/valhalla/) for the latest >> state of the project code, keeping in mind that it may lag several days >> behind `jdk/master`. Both repositories may be needed as references during >> review. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3234975617
