Summary

Deprecate the flag UseCompressedClassPointers, with the intent to remove the flag and implementation of uncompressed class-pointers in a future release.

Motivation

Shortly after the adoption of 64-bit architectures the -XX:[-|+]UseCompressedClassPointers and -XX:[-|+]UseCompressedOops arguments were added to provide Java users the ability to enable using 32-bit references even when on a 64-bit architecture. This reduces memory overhead and help reduce cache misses. Originally, the two flags were coupled, which meant that +UseCompressedClassPointers depended on +UseCompressedOops. Starting in JDK 15, the two options have been decoupled, which means that +UseCompressedClassPointers can be used indepent from +UseCompressedOops. This greatly reduced the need for -UseCompressedClassPointers. JDK-8332514 extended the addressable class-space of compressed classes to 4GB and JDK-8338526 moved interface and abstract classes out of class-space, both of which further reduce the need for -UseCompressedClassPointers.

On the other hand, maintaining the code to support uncompressed class-pointers is an on-going cost, and having alternative code-paths in performance-critical code such as the accessor for loading the Klass* out of an object has shown to impact performance in some situations. In the long run, the HotSpot JVM should settle on a single object header layout.

Deprecating the flag UseCompressedClassPointers will allow us to remove the flag in a future release, and thus reduce maintenance burden, improve performance and pave the way for a single object header layout.

Description

An attempt to run with [+/-]UseCompressedClassPointers will produce:

WARNING: The flag UseCompressedClassPointers is deprecated and may be removed in a future release.

Alternatives

TBD: maybe describe near-/far-Klass approach.

Risks and Assumptions

There is a risk that an application might need more than 4GB of class-space (roughly 4 million addressable classes with +UseCompactObjectHeaders, 5-6 million classes with -UseCompactObjectHeaders). Realistically, this can only be achieved by generating a lot of classes. JDK-8338526 reduces that risk by avoiding to place interface and abstract classes into class-space to begin with - many generated classes are all-static classes and can be treated as abstract classes.

If there is a pressing need to support more than 4 million classes / 4GB of class-space, we can implement near/far-Klasses proposal, which would support addressing virtually unlimited number of classes using compressed class-pointers. However, this would likely come at a cost, and should therefore only be considered if really necessary.

Dependencies

The 32 bit JVMs currently use uncompressed class-pointers. Before UseCompressedClassPointers can be obsoleted in a future release, the 32 bit JVMs need to be changed to use compressed class-pointers (which would mean a kind of fake compressed class-pointers, because there is no need to compress anything).