close

JEP 534: Compact Object Headers by Default

OwnerRoman Kennke
TypeFeature
ScopeJDK
StatusProposed to Target
Release27
Componenthotspot / runtime
Discussionhotspot dash runtime dash dev at openjdk dot org
EffortXS
DurationXS
Relates toJEP 519: Compact Object Headers
Reviewed byVladimir Kozlov
Endorsed byVladimir Kozlov
Created2025/07/01 13:36
Updated2026/05/12 12:12
Issue8361187

Summary

Make compact object headers the default object header layout in the HotSpot JVM. Compact object headers reduce object headers from 96 bits down to 64 bits on 64-bit architectures, thereby reducing heap size, improving deployment density, and increasing data locality.

Non-Goals

Motivation

Compact object headers were introduced as an alternative object-header layout via JEP 450 (JDK 24), and turned into a full product feature via JEP 519 (JDK 25). Features of this size are best introduced carefully and gradually, so we have not turned it on by default, yet.

Since JDK 24, compact object headers have proven their stability and performance.

They have been tested at Oracle by running the full JDK test suite. They have also been tested at Amazon and SAP. Amazon runs hundreds of services in production with compact object headers, most of them using backports of the feature to JDK 21 and JDK 17. SAP has already switched to compact object headers by default in their downstream OpenJDK fork, the SapMachine; they run a large suite of tests daily and have a large customer base.

Various experiments demonstrate that enabling compact object headers improves performance:

It is time to make compact object headers the default mode. We intend to deprecate the old object header layout in a future release.

Description

Compact object headers are enabled in JDK 25 via the command-line option

$ java -XX:+UseCompactObjectHeaders ...

That option will no longer be needed once compact object headers are the default. You can disable the feature, if needed, by running with:

$ java -XX:-UseCompactObjectHeaders ...

Testing

Compact object headers were subjected to massive testing as part of JEP 450 and JEP 519. Another full round of correctness and performance testing will be done before integrating this change.

Risks and Assumptions

As discussed in JEP 450, future features may require additional object-header bits. We have already reserved four bits for Project Valhalla. If a need for even more bits arises, we can shrink compressed class pointers and identity hash codes even further, using techniques we have already prototyped in Project Lilliput.