RFR: 8363996: Obsolete UseCompressedClassPointers

[David Holmes]

On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe <stuefe at openjdk.org> 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