On Fri, 3 Jul 2026 11:07:54 GMT, David Simms <[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). > > David Simms has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 2900 commits: > > - Merge branch '8317277' into jep401_sub_review_8317278 > - Merge remote-tracking branch 'valhalla/lworld' into 8317277 > - Merge > > Merge jdk-28+5 > - 8386602: [lworld] C2: assert(n != top() || r->in(pnum) == top()) failed: > live value must not be garbage > > Reviewed-by: thartmann > - 8386499: [lworld] java/util/Arrays/ArraysEqCmpTest.java fails with > unexpected layoutKind 5 > > Reviewed-by: chagedorn > - 8387629: [lworld] Don't use apiNote for some recent JDI spec updates > > Reviewed-by: sspitsyn > - 8387682: [lworld] Mention preview API in description of > can_support_value_objects capability > > Reviewed-by: cjplummer > - 8387657: [lworld] Object Tags section of JVMTI spec should make it clear > that ObjectFree event is not sent for value objects > > Reviewed-by: sspitsyn, cjplummer > - 8382226: [lworld] C2: Fix _copyOf/_copyOfRange intrinsic for flat abstract > value class arrays > > Reviewed-by: qamai, thartmann > - 8387612: [lworld] C2: assert(array_type->is_flat() || > ideal.ctrl()->in(0)->as_If()->is_flat_array_check(&_gvn)) failed: Should be > found > > Co-authored-by: Marc Chevalier <[email protected]> > Reviewed-by: thartmann > - ... and 2890 more: https://git.openjdk.org/jdk/compare/db987b1e...f1f6d35d src/hotspot/share/c1/c1_LIRGenerator.cpp line 777: > 775: if (expected_type != nullptr && expected_type->is_obj_array_klass()) > { > 776: // For a direct pointer comparison, we need the refined array > klass pointer > 777: expected_type = > ciObjArrayKlass::make(expected_type->as_array_klass()->element_klass()); It would be clearer what was happening here if the "refined_type" argument to make() wasn't hidden as the default. Suggestion: expected_type = ciObjArrayKlass::make(expected_type->as_array_klass()->element_klass(), true /* refined_type */); Also, is it possible that `expected_type` is already refined here? src/hotspot/share/ci/ciObjArrayKlass.cpp line 203: > 201: ciKlass* ciObjArrayKlass::exact_klass() { > 202: // This cannot be an exact klass because the refined types subtype it > 203: return nullptr; This seems overly conservative. Shouldn't we at least allow the old code when Valhalla --enable-preview features are turned off? Even when Valhalla features are turned on, I suspect that there are situations where we can do better than always returning nullptr. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3540377423 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3540327826
