JDK-8365823 : Revert storing abstract and interface Klasses to non-class metaspace
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-08-19
  • Updated: 2025-09-26
  • Resolved: 2025-09-19
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 26
26 b17Fixed
Related Reports
Relates :  
JDK-8343218 - Add option to disable allocating interface and abstract classes in non-class metaspace
Relates :  
JDK-8338526 - Don't store abstract and interface Klasses in class metaspace
Relates :  
JDK-8361211 - C2: Final graph reshaping generates unencodeable klass constants
Description
The change to store interface and abstract classes to non-class metaspace doesn't save that much space in the class metaspace or materially increase the number of classes that can be stored there, and it's found to have obscure bugs in C2 and other parts of the system.  So this should be reverted.  All Klasses should be stored in Class Metaspace if UseCompressedKlassPointers (deprecated) is true.
Comments
Fix Request: This fix reverts an optimization that was added, which has been found to have subtle compilation bugs. The optimization is only a space optimization and hadn't been observed to be a problem to date. This fix restores the code to what it was from JDK 8 to before JDK 24. The change is small and low risk.
26-09-2025
Changeset: fa00b249 Branch: master Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2025-09-19 11:54:34 +0000 URL: https://git.openjdk.org/jdk/commit/fa00b24954d63abed0093b696e5971c1918eec4d
19-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27295 Date: 2025-09-15 13:28:45 +0000
15-09-2025
A data-point for eventual 25u backport: We have backported the feature flag (JDK-8343218) and flipped the flag off by default in Corretto 25, as we judged the reliability risk is too high for the optimization gain. The pre-release testing is running now, we expect no problems. If you at any time feel this RFE gets too far into the weeds of which code paths to remove, consider just flipping the flag off by default in a straightforward RFE, and then deal with the rest.
25-08-2025
I agree with Thomas: `is_in_encoding_range` and `is_encodable` should stay, they are still useful to check that the compressed klass pointer is legit. This also means JDK-8361211 should also stay for a while.
25-08-2025
All the callers of that function pass Klass* so I think it's signature should be Klass* and then do your casts inside it. Once UseCompressedKlassPointers is removed (which part of me is not that excited about since gdb will be more difficult), it should always return true right?
20-08-2025
Hi [~coleenp], about `is_encodable`: If !UseCompressedKClassPointers, then the Klass range is empty (zero-sized), which means the result will always be false. That was kind of intentional, but maybe I was too much of a smart ... and should just have written it out instead. But yes, I am working on a change that will remove UCCP, hope to get it out of the door sometime next week for initial review. I would leave the function in. It is useful enough for verification.
20-08-2025
I'm not sure https://github.com/openjdk/jdk/commit/e304d37996b075b8b2b44b5762d7d242169add49 needs to be reverted though, in case of !UseCompressedKlassPointers (which is going away though). Maybe it should be an assert? Or should ciKlass::is_in_encoding_range() also be removed?
20-08-2025
And this. Some of the callers ask UseCompressedKlassPointers first but others don't. Always called with Klass* but I don't know if this was introduced to handle interface and abstract classes and should also be removed (?). Although _klass_range_start and end might be all of metaspace if UseCompressedKlassPointers is off but some code thinks it then can encode the Klass pointer. // Returns whether the pointer is in the memory region used for encoding compressed // class pointers. This includes CDS. static inline bool is_encodable(const void* addr) { // An address can only be encoded if: // // 1) the address lies within the klass range. // 2) It is suitably aligned to 2^encoding_shift. This only really matters for // +UseCompactObjectHeaders, since the encoding shift can be large (max 10 bits -> 1KB). return (address)addr >= _klass_range_start && (address)addr < _klass_range_end && is_aligned(addr, klass_alignment_in_bytes()); }
20-08-2025