On Mon, 1 Jun 2026 09:03:34 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 2754 commits: > > - Merge remote-tracking branch 'valhalla/lworld' into > jep401_sub_review_8317278 > - Merge > > Merge jdk-27+24 > - 8385674: [lworld] TestNullableInlineTypes.java fails after JDK-8325632 > > Reviewed-by: mchevalier > - 8385652: [lworld] RedefineClasses should use stack map frame name > > Reviewed-by: fparain > - 8384107: [lworld] Update runtime/contended tests to run the same testing > for value classes > > Reviewed-by: fparain, lmesnik > - 8385600: [lworld] DA/DU issues with strict fields > > Reviewed-by: vromero > - 8384897: [lworld] this.staticField should be restricted in early > construction context > > Reviewed-by: liach, vromero > - 8385601: [lworld] Update testing documentation for the ValueClassPlugin > jtreg option > > Reviewed-by: lmesnik > - 8385569: [lworld] Apply JDK-8343767 to Valhalla specific StubRoutines > > Reviewed-by: fparain, vlivanov > - 8385581: [lworld] Remove the experimental JVMCI feature > 8382708: [lworld] JVMCI support for Value Objects > 8372605: [lworld] > compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJava*.java > fail with --enable-preview > > Reviewed-by: thartmann > - ... and 2744 more: https://git.openjdk.org/jdk/compare/2c7efc08...e0250a38 src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1095: > 1093: /* Computation of inline classes has a slightly different strategy than > for > 1094: * regular classes. Regular classes have their oop fields allocated at > the end > 1095: * of the layout to increase GC performances. Unfortunately, this > strategy Suggestion: * of the layout to increase GC performance. Unfortunately, this strategy src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1146: > 1144: // PADDING is inserted if needed to ensure the correct alignment of > the payload. > 1145: if (_is_abstract_value && _has_nonstatic_fields) { > 1146: // non-static fields of the abstract class must be laid out > without knowing Suggestion: // Non-static fields of the abstract class must be laid out without knowing src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1167: > 1165: // is computed. Super abstract value classes might have been too > conservative > 1166: // regarding alignment constraints, but now that the full set of > non-static fields is > 1167: // known, compute which alignment to use, then set first allowed > field offset Suggestion: // known, compute which alignment to use, then set first allowed field offset. src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1218: > 1216: // At this point, the characteristics of the raw layout (used in > standalone instances) are known. > 1217: // From this, additional layouts will be computed: atomic and > nullable layouts > 1218: // Once those additional layouts are computed, the raw layout might > need some adjustments Suggestion: // From this, additional layouts will be computed: atomic and nullable layouts. // Once those additional layouts are computed, the raw layout might need some adjustments. src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1237: > 1235: } > 1236: > 1237: // Next step is the nullable layouts: they must include a null > marker Suggestion: // Next step is the nullable layouts: they must include a null marker. src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1301: > 1299: // we want the raw layout to have the same alignment as those > atomic layouts so access codes > 1300: // could remain simple (single instruction without intermediate > copy). This might required > 1301: // to shift all fields in the raw layout, but this operation is > possible only if the class Suggestion: // could remain simple (single instruction without intermediate copy). This might require // shifting all fields in the raw layout, but this operation is possible only if the class src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1348: > 1346: // if the inline class has a null-free atomic layout, the the > layout used in heap allocated standalone > 1347: // instances must have at least equal to the atomic layout to allow > safe read/write atomic > 1348: // operation Suggestion: // If the inline class has a null-free atomic layout, then the layout used in heap allocated standalone // instances must have at least equal to the atomic layout to allow safe read/write atomic // operation. src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1502: > 1500: // null marker is zero (field is null), then all the fields > of the flat field are also > 1501: // zeroed. So, nullable flat field are not encoded > different than null-free flat fields, > 1502: // all fields are included in the map, plus the null marker Suggestion: // all fields are included in the map, plus the null marker. src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1506: > 1504: // require a dedicated section in the acmp map, and be > handled differently: null_marker > 1505: // comparison first, and if null markers are identical and > non-zero, then conditional > 1506: // comparison of the other fields Suggestion: // comparison of the other fields. src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1609: > 1607: // which prints the details of LayoutRawBlocks used to compute the > layout. > 1608: // The code below checks that offsets in the _field_info meta-data > match offsets > 1609: // in the LayoutRawBlocks Suggestion: // in the LayoutRawBlocks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338199177 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338202987 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338204181 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338205762 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338207097 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338214786 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338219591 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338224149 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338225269 PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3338226906
