How Compact Object Headers in Java 25 Slash Memory Usage and Boost Performance

Introduction

JEP 519, delivered in JDK 25, promotes the experimental compact object header introduced by JEP 450 (Java 24) to a standard HotSpot JVM feature. The goal is to shrink the mandatory object header on 64‑bit platforms from 96‑128 bits to a single 64‑bit word (8 bytes), thereby reducing per‑object memory overhead and improving cache behavior.

Motivation

Typical Java objects of 256‑512 bits would spend >20 % of their memory on the header.

Reducing the header cuts overall heap size, increases deployment density, improves data locality, and lowers garbage‑collection (GC) pressure.

Original Header Layout

On a 64‑bit HotSpot JVM each object starts with:

Marker word (64 bits) – stores identity hash code, GC age, forwarding pointer, and lock bits.

Compressed class pointer (32 bits) – a reference to the class metadata in the metaspace.

For arrays, a third length field (32 bits).

The combined size is therefore 96‑128 bits depending on alignment and the presence of the array length field.

Compact Object Header Design

Header Merging

The compact layout merges the compressed class pointer into the marker word, eliminating the separate class‑pointer field. The resulting 64‑bit header contains:

Compressed class pointer (22 bits after re‑encoding).

Identity hash code (31 bits).

GC age, mark bits, and a self‑forwarding flag (4 bits).

Four spare bits reserved for future use (e.g., Project Valhalla).

Enabling the layout automatically activates compressed class pointers, reducing the encoding from 32 bits to 22 bits and limiting the number of simultaneously loaded classes to roughly four million – sufficient for most applications.

Locking Changes

Lightweight (biased) locking now uses a subset of the header bits to indicate lock state (occupied vs. free) without moving or expanding the header. Heavyweight (monitor) locks still allocate a separate monitor object, but only the mark bits in the header are updated. The legacy stack‑locking path has been removed.

GC Forwarding

During object relocation, all HotSpot collectors except ZGC write a forwarding pointer into the header. A dedicated bit marks the object as self‑forwarded, and the lower 42 bits of the header hold the new address, fitting within the compact layout.

Compressed Class Pointers

Compressed class pointers become mandatory for the compact layout. The reduced address space caps the total number of loaded classes at ~4 M. JIT compilers that cannot handle the layout (e.g., some Graal configurations) automatically disable the feature.

Enabling the Feature

Because the compact header was experimental, it is disabled by default. It can be turned on at runtime with the following JVM options:

-XX:+UnlockExperimentalVMOptions
-XX:+UseCompactObjectHeaders

In JDK 25 the flag -XX:+UseCompactObjectHeaders is promoted to a product feature, so only the unlock flag is required for earlier releases.

Observed Benefits

Memory savings: Header size drops from up to 16 bytes to 8 bytes, yielding a 10‑20 % reduction in total heap usage for workloads dominated by small objects.

Reduced GC pressure: Smaller heaps lead to fewer GC cycles and shorter pause times, especially for allocation‑heavy applications.

Improved data locality: Objects fit more densely into CPU cache lines, decreasing cache‑miss rates during traversal.

Benchmark Results

SPECjbb2015 – one configuration showed a 22 % heap reduction and an 8 % decrease in CPU time.

SPECjbb2015 with G1 or Parallel collectors (ZGC not supported) – GC time reduced by ~15 %.

Highly parallel JSON‑parsing benchmark – overall runtime improved by ~10 %.

Risks and Compatibility

The compact header consumes a limited set of bits; future JVM features could exhaust the remaining spare bits, requiring careful coordination. Additionally, JVMCI on x86‑64 does not support the compact layout, so enabling the feature when JVMCI is active should be avoided.

JIT compilers that lack support automatically disable the feature, preventing regressions in Graal or other JVMCI‑based compilers. Extensive testing under concurrent workloads is recommended to validate correctness and performance.

Conclusion

JEP 519 introduces a 64‑bit compact object header that merges the class pointer into the marker word, reduces per‑object memory overhead, and delivers measurable improvements in heap size, GC latency, and cache efficiency. The change also prepares the HotSpot JVM for future enhancements while maintaining compatibility with existing Java applications.