On Wed, 13 May 2026 05:53:57 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/cpu/aarch64/gc/g1/g1_aarch64.ad line 98: > >> 96: >> 97: // Extract the narrow oop field value >> 98: __ ubfm($tmp1$$Register, $src$$Register, 0, 31); > > Using `uxtw` or `movw` here might be more clear if the value is always the > low word and not an arbitrary bitmask. Makes sense. Would you mind filing an RFE or simply add a comment to JDK-8350865? > src/hotspot/share/opto/inlinetypenode.cpp line 2331: > >> 2329: } >> 2330: >> 2331: Node* shift_val = igvn.intcon(offset << LogBitsPerByte); > > The way values are packed and then read or written in the x86 and aarch64 > back-end seems to imply little-endian. For big-endian, it seems like we need > to pack in different order, or force the back-end to byte-swap. Yes, current code around flattening is all little-endian. Once flattening is implemented on a big-endian platform, we need to adjust this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3264524149 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3264508971
