Bug ID: JDK-8354070 Support Compact Object Headers as product option

Type: CSR
Component: hotspot
Sub-Component: runtime

Priority: P3
Status: Closed
Resolution: Approved
Fix Versions: 25

Submitted: 2025-04-08
Updated: 2025-05-14
Resolved: 2025-05-13

Summary
-------

The option -XX:+/-UseCompactObjectHeaders is now a product option, and no longer experimental.

Problem
-------

The compact object headers feature (JEP 450) reduces memory footprint and potentially improves performance of Java applications. The option should be available to all users without requiring -XX:+UnlockExperimentalVMOptions. Going forward, the option should become enabled by default in a future release.

Solution
--------

Remove experimantal status of the flag UseCompactObjectHeaders.

Specification
-------------

```
diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp
index ab975b1b375c0..90b31f841507c 100644
--- a/src/hotspot/share/runtime/globals.hpp
+++ b/src/hotspot/share/runtime/globals.hpp
@@ -128,7 +128,7 @@ const size_t minimumSymbolTableSize = 1024;
           "Use 32-bit class pointers in 64-bit VM. "                        \
           "lp64_product means flag is always constant in 32 bit VM")        \
                                                                             \
-  product(bool, UseCompactObjectHeaders, false, EXPERIMENTAL,               \
+  product(bool, UseCompactObjectHeaders, false,                             \
           "Use compact 64-bit object headers in 64-bit VM")                 \
                                                                             \
   product(int, ObjectAlignmentInBytes, 8,                                   \
```

Moving to Approved.
13-05-2025
[~darcy] Thanks for the clarification. I moved to Finalized now.
13-05-2025
[~rkennke], per the process https://wiki.openjdk.org/display/csr/Main you put the CSR back in Proposed state which requested it go through the first phase of CSR review again. To request the CSR go through the second phase, the CSR should be Finalized. HTH
13-05-2025
[~darcy]: > Moving back to Provisional after JEP association. Why? When should I move it back to proposed? I don't quite understand the process, I suppose.
13-05-2025
Moving back to Provisional after JEP association.
13-05-2025
We now have associated JEP 519.
13-05-2025
Hi Roman [~rkennke], The new locking scheme didn't have a JEP in the first place, so slightly different circumstances there. This was raised with Alex and Mark and they have indicated that a new JEP should be done. To paraphrase the reasoning: The reason we label VM features as experimental is because they have moderate risk (and JEP 450 spells out the risk of C.O.H.). If the feature has been derisked enough to have production status in JDK 25 then users want and need to know that, and the best vehicle for that (rather than a release Note or a CSR request), is a JEP. I think ZGC's JEP 377 is a good model for moving a feature from Experimental to Production. You should explain how all the risks and assumptions in the initial C.O.H. JEP have been addressed such that the feature is clearly now ready be put into production by customers (but still not the default). And as per this CSR request above "Report and confirm performance information on the latest version of the software. Verify that this is acceptable and expected."
11-04-2025
I am pretty sure that we transitioned a couple of experimental flags to product flag without a JEP. For example, we made LockingMode a product flag in JDK-8315061, and haven't published a JEP for that. UseCompactObjectHeaders seems similar: a flag to facilitate transitioning to a new feature, with the end-goal that the flag and old code ultimately get removed. I would avoid making a JEP for it, unless it's really really necessary.
10-04-2025
[~darcy] No there is no JEP associated with this, but I'm assuming now that there should be to transition a feature from Experimental to Product - ref for example ZGC: https://openjdk.org/jeps/377. I'm unclear if there is a process document actually stipulating this though?
10-04-2025
[~coleenp] only the assignee can change the state of a CSR request.
10-04-2025
[~liach] For hotspot flags we use the changes to the globals.hpp file as the "specification" (usually the flag table because it shows how the flag is to be deprecated/obsoleted/expired).. Very few hotspot flags are actually documented on the `java` command reference page, as very few are intended for regular use by the end-user. Experimental flags are not documented at all - the features they pertain too are typically exposed via other means e.g. the JEP that produced them. Once this flag is a product flag then it may be appropriate to document in the command reference.
10-04-2025
Moving to Provisional, not Approved. Is there a JEP associated with this work for JDK 25?
10-04-2025
typo: experimantal
09-04-2025
FYI specification changes include changes to API specification or tools specification; it does not include changes to C++ files. That said, while reviewing tools specification, I noticed this flag is mising from https://docs.oracle.com/en/java/javase/24/docs/specs/man/java.html#advanced-runtime-options-for-java the man pages for the `java` command line tool, while other flags listed nearby in globals.hpp is present. I don't know what's the best way forward with this situation - should the flag be added to 25 only, and in the same patch or in a separate patch?
09-04-2025
I think the next state is finalized and am I the only one that can set it?
09-04-2025
Reviewed. We are running a PIT test on this product option. We did run PIT on the option as experimental as well.
08-04-2025

CSR :	JDK-8354672 - JEP 519: Compact Object Headers
CSR :	JDK-8350457 - Implement JEP 519: Compact Object Headers