Summary

Change Compact Object Headers from an experimental to a product feature.

Non-Goals

This JEP does not propose to make Compact Object Headers the default object header layout.

Motivation

Compact Object Headers have been introduced as an alternative object header layout in JEP 450. Features of that size are best introduced carefully and gradually, so it has been introduced as an experimental feature.

Since its introduction in JDK 24, a number of issues have been fixed. The feature has proven its usefulness and stability both in the official JDK 24 release as well as in backports to JDK 21 and JDK 17, as used internally by hundreds of services at Amazon. Therefore it is time to remove its experimental status and make it a product feature.

Description

Compact Object Headers are enabled today via the -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders command-line options. Making Compact Object Headers a product (non-experimental) feature means that the -XX:+UnlockExperimentalVMOptions option will no longer be needed. We will not change the default values for this option.

Testing

Testing of Compact Object Headers was added as part of JEP 450. The feature has been tested by running the full OpenJDK test suite at Oracle with the feature turned on. It has also been tested at Amazon by hundreds of services that run it in production (most of them via backports to JDK 21 and JDK 17). No additional tests will be developed as part of this JEP.

Some tests currently supply the -XX:+UnlockExperimentalVMOptions command-line option when enabling Compact Object Headers. This will no longer be needed, and these tests will be adjusted accordingly.

Risks and Assumptions

As discussed in the original JEP 450, future features and projects may need header bits. In particular, it is currently known that Project Valhalla may need 3 or 4 header bits. This is currently addressed by leaving 4 spare bits in the header. If there ever arises a need for more header bits, the class pointer compression can be improved and/or the identity hash-code can be changed to require fewer bits. For both approaches there exist proofs-of-concept in the Lilliput project.

Performance

Various experiments have shown that enabling compact object headers benefits performance. For example, Roman Kennke has shown in his 2025 FOSDEM presentation, that heap usage is reduced by >20% and CPU usage is reduced by 8% in SPECjbb2015 benchmark. Stefan Johansson has shown positive effects on GC: compact object headers reduce the number of GCs by about 15% and helps avoid object promotions to old generation [2]. Anecdotally, users are reporting 10% CPU reduction in a JSON parser benchmark.