JDK-8360700 : Implement Compact Object Headers enabled by default
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 26
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-06-26
  • 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.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8365493 - Regression on Pet Clinic app with Compact Object Headers
Blocks :  
JDK-8372152 - Parallel: SIGSEGV in PSYoungGen at oopDesc::verify
Blocks :  
JDK-8372151 - G1: SIGSEGV in G1HeapRegion::verify_liveness_and_remset
Relates :  
JDK-8366042 - Creates Object Headers Microbenchmark Set.
Relates :  
JDK-8354672 - JEP 519: Compact Object Headers
Relates :  
JDK-8361187 - Compact Object Headers by Default
Description
We should make compact object headers enabled by default, to give Java users the benefits without any hurdles.
Comments
To update the status of JDK-8365493: Regression on Pet Clinic app with Compact Object Headers, this is viewed as a blocking issue to changing the default to Compact Object Headers. [~aartemov] and [~fbredberg] have been investigating and are posting their findings in the issue but since the issue is assigned to [~rkennke] we expect that this is also being investigated on your end. In addition, due to this regression, it is important before changing the default to Compact Object Headers to post the level and duration of testing that Compact Object Headers has undergone in this implementation task CR in order to ensure that it is ready to be the default.
01-10-2025
[~rkennke] I agree, we can deprecate the non-compact mode by deprecating the UseCompactObjectHeaders option. Also note, that the future removal of non-compact mode and obsolescence of the option will need a JEP, much like generational ZGC, see JEP 490: ZGC: Remove the Non-Generational Mode, JDK-8335850.
27-06-2025
[~rkennke] Moving Compact Object Headers to the default should have a JEP and a CSR, much like the progression of moving generational ZGC from product to default. See JEP 474: ZGC: Generational Mode by Default, JDK-8326667. Like JEP 519: Compact Object Headers, you should explain how all the risks and assumptions in the C.O.H. JEP 519 have been addressed such that the feature is clearly now ready be put into default. Equally as important is to "Report and confirm performance information on the latest version of the software. Verify that this is acceptable and expected."
27-06-2025
[~rkennke] As per the ZGC switch, I would expect this one to read something like: "Switch the default mode of object headers to the compact mode. Deprecate the non-compact mode, with the intent to remove it in a future release."
26-06-2025
[~lfoltan] btw, how about deprecation? I would like to also deprecate the UseCompactObjectHeaders as soon as possible, ideally also in JDK26. Would it make sense to do this under the same JBS issue/CSR/JEP? I don't feel like duplicating all the red tape for that follow-up step makes a whole lot of sense. WDYT?
26-06-2025
[~lfoltan] Thank you for the info, I wanted to ask about that anyway. :-) And yea, I expected something like this. However, the argumentation for it will be pretty much the same as for JEP 519, unless anything unexpected comes up in JDK25 timeframe.
26-06-2025