On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <[email protected]> wrote:
> _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to > push it once JDK 27 opens. > > 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. This was > implemented with JDK-8363998 [3] - for more details, please see that issue > and its PR. > > 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... About a third of the way through. Mostly all pretty straight-forward but unclear why a number of _LP64 guards can be removed? src/hotspot/share/cds/aotMetaspace.cpp line 1853: > 1851: // > 1852: // The range encompassing both spaces will be suitable to en/decode > narrow Klass > 1853: // pointers: the base will be valid for encoding, the range [Base, > End) and not Suggestion: // pointers: the base will be valid for encoding the range [Base, End) and not src/hotspot/share/cds/archiveBuilder.cpp line 671: > 669: dump_region->allocate(sizeof(address)); > 670: } > 671: #ifdef _LP64 Not obvious this isn't still needed. src/hotspot/share/cds/archiveBuilder.cpp line 1140: > 1138: }; > 1139: > 1140: #ifdef _LP64 Again not clear why this can be removed. ------------- PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3538084962 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587534751 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587540478 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587563999
