-
Sub-task
-
Resolution: Delivered
-
P4
-
25
The option `UseCompressedClassPointers` is deprecated in Java 25 and will be removed in a future Java version.
This option was used to switch between two modes:
- The compressed class pointer mode (`-XX:+UseCompressedClassPointers`, default if the switch is not specified)
- The uncompressed class pointer mode (`-XX:-UseCompressedClassPointers`)
The uncompressed class pointer mode will be removed in a future version of Java; since that only leaves the default compressed class pointer mode, the switch will also be removed.
The uncompressed class pointer mode causes the JVM to use more memory. It serves very little purpose today.
The default compressed class pointer mode causes the JVM to place classes into the class space; the class space is limited by default to 1GB and can hold up to ~1.5 million classes. In the rare case that an application must load more than that, the class space can be extended up to 4 GB with `-XX:CompressedClassSpaceSize` . That increases the number of classes the class space can hold to ~6 million classes.
Note that these numbers are extremely high; it is rare even for a huge Java application to even load more than 100,000 classes. If your application loads significantly more classes than that, it is very likely a pathological situation, such as a class loader leak.
The class space is reserved up front when the JVM starts. However, that memory is virtual: no actual memory is used until classes are loaded, and then, only as many pages are allocated as are needed to hold the class data.
If your application specifies `-XX:+UseCompressedClassPointers`, remove that option. It is superfluous since enabling compressed class pointers is the default.
If your application specifies `-XX:-UseCompressedClassPointers`, remove that option. In all likelihood, the application will just continue to work. Should the application exhaust the class space, you may want to examine whether that situation is pathological. If it is not pathological, increase the class space to 4GB using `-XX:CompressedClassSpaceSize=4g`.
This option was used to switch between two modes:
- The compressed class pointer mode (`-XX:+UseCompressedClassPointers`, default if the switch is not specified)
- The uncompressed class pointer mode (`-XX:-UseCompressedClassPointers`)
The uncompressed class pointer mode will be removed in a future version of Java; since that only leaves the default compressed class pointer mode, the switch will also be removed.
The uncompressed class pointer mode causes the JVM to use more memory. It serves very little purpose today.
The default compressed class pointer mode causes the JVM to place classes into the class space; the class space is limited by default to 1GB and can hold up to ~1.5 million classes. In the rare case that an application must load more than that, the class space can be extended up to 4 GB with `-XX:CompressedClassSpaceSize` . That increases the number of classes the class space can hold to ~6 million classes.
Note that these numbers are extremely high; it is rare even for a huge Java application to even load more than 100,000 classes. If your application loads significantly more classes than that, it is very likely a pathological situation, such as a class loader leak.
The class space is reserved up front when the JVM starts. However, that memory is virtual: no actual memory is used until classes are loaded, and then, only as many pages are allocated as are needed to hold the class data.
If your application specifies `-XX:+UseCompressedClassPointers`, remove that option. It is superfluous since enabling compressed class pointers is the default.
If your application specifies `-XX:-UseCompressedClassPointers`, remove that option. In all likelihood, the application will just continue to work. Should the application exhaust the class space, you may want to examine whether that situation is pathological. If it is not pathological, increase the class space to 4GB using `-XX:CompressedClassSpaceSize=4g`.