JDK-8363996 : Obsolete UseCompressedClassPointers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P2
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2025-07-24
  • Updated: 2025-12-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 27
27Unresolved
Related Reports
CSR :  
JDK-8372065 - Obsolete UseCompressedClassPointers
Relates :  
JDK-8350753 - Deprecate UseCompressedClassPointers
Relates :  
JDK-8371885 - Mark UseCompressedClassPointers as obsolete for JDK 27
Sub Tasks
JDK-8363998 :  
Implement Compressed Class Pointers for 32-bit - Resolved
JDK-8364310 :  
Release Note: The UseCompressedClassPointers Option Is Now Obsolete - Open
Description
UseCompressedClassPointers, deprecated with JDK 25 (JDK-8350753), should be made obsolete, and its maintaining code removed as well.

One roadblock before this is the ongoing existence of the two remaining 32-bit platforms: arm32 and zero 32bit. 32-bit platforms rely on -UseCompressedClassPointers, so removing that code will break 32-bit. We need to figure out what to do with those first.

Update: The 32-bit issue was resolved with JDK-8363998.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/28366 Date: 2025-11-18 08:17:37 +0000
03-12-2025
Thanks [~stuefe]!
17-11-2025
[~dholmes] I ran into an unspecified problem when working on the patch, and find it too risky to do this in this short a time frame until JDK 26 freezes. I planned to move this to early JDK 27, but post a patch for discussion beforehand. I will take care of the failing test.
14-11-2025
[~stuefe] what is the status of this work for 26? We have reach the point in the release lifecycle where the gtest that checks for "special flag" validity is now failing in tier1 because this flag has not actually been obsoleted in JDK 26. If this work is still targetted to 26 then we will need a temporary change to stop the test failing. If we are retargetting to a later release then we need to update the entry in arguments.cpp. Either way, something needs to be done in relation to this. Thanks.
14-11-2025
RT Triage: [~stuefe] obsolescence is the next step ahead of removal according to runtime/arguments.cpp.
29-07-2025