Today's compressed class pointers encode a 64-bit pointer into 32 bits. Introduced with JDK 8, compressed class pointers first depended on compressed object pointers; with JDK 15, this dependency was removed (JDK-8241825). Enabling compressed class pointers is highly desirable. Today, only two reasons remain that require an application to disable compressed class pointers:
- It uses JVMCI, which on some platforms inhibits the use of compressed class pointers.
- It loads more than roughly three million classes. This limit is imposed by the way class space is implemented today. Note that the latter limit is theoretical - an application that hits this limit would use approximately six to ~30 GB for metaspace alone; we have yet to find an application that does.
Compact object headers will limit the bits available to identify a class to 32 bits or less. The feature, therefore, requires compressed class pointers to be enabled unconditionally. The cases mentioned above will consequently prevent compact object headers from being used. They must be solved before eventually removing legacy object header handling for good. They need not be solved as long as compact object headers are optional since the option to switch them off remains.
Today's compressed class pointer encoding uses the 32 bits of a compressed pointer as an offset into the class space. This is inefficient since it wastes many value points in this 32-bit value. As part of this JEP, the encoding will be modified so that the JVM can express a much larger number of classes within the same number of bits. In addition to that, we will shrink the number of bits used to at least 24 bits. For further information see [xx]
[xx] Smaller class pointers.