On Tue, 24 Mar 2026 06:25:40 GMT, Thomas Stuefe <[email protected]> wrote:
>> This change removes the uncompressed Klass pointer mode and, with compressed >> Klass pointers remaining as the only option, the >> `UseCompressedClassPointers` switch. >> >> For motivation, please take a look at CSR associated with the deprecation >> (which we did for JDK 25) and the preparatory discussion we had at the start >> of the year around this topic [2]. >> >> This patch is quite invasive and touches many parts of the JVM, since its >> goal is to remove most traces of the uncompressed Klass path and to take >> advantage of opportunities for simplification. In some cases, I did not take >> opportunities for further simplification to keep the patch somewhat legible; >> it will be onerous enough to review. >> >> ### Implementation Notes >> >> With uncompressed Klass pointers removed, we have three modes of operation >> left (including 32-bit): >> a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. >> This is now the standard mode until we run with COH by default. >> b) 64-bit, COH on >> c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run >> with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. >> The difference to (a, b) is that we don't use a class space. Most of this >> was implemented with JDK-8363998 [3] - here, we just add a compile-time >> switch `INCLUDE_CLASSSPACE`, which is true on 32-bit, false on 64-bit. >> >> I ensured *arm32* builds and I performed some rudimentary checks (selected >> metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an >> interest in arm32 will have to step up and do their own, more thorough unit >> testing. Also, I did not see anyone doing follow-up work after JDK-8363998 >> [3] - so some issues may still lurk from that patch as well (but maybe >> JDK-8363998 was just not breaking anything). >> >> I did not check *zero 32-bit*, the only other platform supporting 32-bit. >> Anyone with an interest in 32-bit zero should chip in. >> >> Pre-existing errors: While working on this patch, I stumbled over a few >> occurrences of old but benign bugs. Mostly old code assuming >> CompressedClassPointers and CompressedOops were still tied together >> (example: Arguments::set_heap_size()). These bugs are implicitly fixed with >> this patch. >> >> ### Testing >> >> - tier 1 2 3 locally on Linux x64 >> - SAP ran their whole set of tests for all the platforms they support. >> >> >> [1] https://bugs.openjdk.org/browse/JDK-8350754 >> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html >> [3] https://bugs.o... > > Thomas Stuefe has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 73 commits: > > - Merge branch 'master' into JDK-8363996-Obsolete-UseCompressedClassPointers > - Update Copyrights > - Merge branch 'master' into JDK-8363996-Obsolete-UseCompressedClassPointers > - Merge commit '137d97131bc044fa090b88eab767913d690bb2e2' into > JDK-8363996-Obsolete-UseCompressedClassPointers > - Merge branch 'master' into JDK-8363996-Obsolete-UseCompressedClassPointers > - removed CompressedKlassPointers::needs_class_space, since we have now > INCLUDE_CLASS_SPACE > - Feedback Roman > - Merge Master > - Merge branch 'master' into JDK-8363996-Obsolete-UseCompressedClassPointers > - Replace Metaspace::using_class_space with define > - ... and 63 more: https://git.openjdk.org/jdk/compare/cc29010a...ff50ff51 Test `tools/jpackage/share/AsyncTest.java` failed on macosx-aarch64 and output does not help at all: [02:46:00.658] [ FAILED ] AsyncTest.test; checks=2 [02:46:00.658] [==========] 1 tests ran [02:46:00.658] [ PASSED ] 0 tests [02:46:00.658] [ FAILED ] 1 test, listed below [02:46:00.658] [ FAILED ] AsyncTest.test; workDir=[test] [02:46:00.658] 1 FAILED TEST Which seems https://bugs.openjdk.org/browse/JDK-8375088 but I am not sure it is the same. Searching places with "failed" shows: [02:45:56.459] [ FAILED ] AsyncTest$AsyncInnerTest.testNativeBundle(16); checks=29 java.lang.AssertionError: Unexpected: Outcome of command [/usr/bin/codesign --verify --deep --strict --verbose=2 AsyncInnerTest/testNativeBundle.70704433/unpacked-dmg/Applications/Foo.app](6) at jdk.jpackage.test.TKit.error(TKit.java:348) at jdk.jpackage.test.TKit.assertUnexpected(TKit.java:898) at jdk.jpackage.test.MacSignVerify.reportUnexpectedCommandOutcome(MacSignVerify.java:319) at jdk.jpackage.test.MacSignVerify.assertSigned(MacSignVerify.java:236) at jdk.jpackage.test.MacSignVerify.assertSigned(MacSignVerify.java:207) at jdk.jpackage.test.MacSignVerify.assertAdhocSigned(MacSignVerify.java:87) at jdk.jpackage.test.MacHelper.verifyUnsignedBundleSignature(MacHelper.java:1087) ... and 2026-03-24 02:45:09.255 diskimages-helper[38241:74098263] _postflightMountPointsAfterDAMount: disk13s1 : /Volumes/Foo aborting because statfs failed - 2. 2026-03-24 02:45:09.260 diskimages-helper[38241:74098263] _postflightMountPointsAfterDAMount: disk13 aborting because no mount point found. 2026-03-24 02:45:10.510 diskimages-helper[38241:74098280] *useEffectiveIDs**** euid/egid changed to 504,10670 (uid/gid is 504,10670) DIHLDiskImageCreate() returned 2 hdiutil: create: returning 2 hdiutil: create failed - No such file or directory I don't think it is related to your changes. There are several bugs filed on this test for the past few months. It was tier1,tier2,tier3,hs-comp-stress testing. I submitted high tiers testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-4119642780 PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-4119646875 PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-4119653465
