The enhancement addresses a long-standing inefficiency in Java’s memory model where object headers can consume over 20% of heap space in applications with many small objects. By compressing the traditional 96-bit header into 64 bits, applications utilizing frameworks such as Spring Boot, microservices architectures, and data processing pipelines can achieve immediate performance improvements.
In HotSpot JVM, all objects reside in the Java heap, which is a contiguous area within the process’s C heap. Java handles objects exclusively by reference, meaning that local variables contain pointers from stack frames into the Java heap, object fields of reference type point between heap locations, and every reference targets the start of an object header.
This mandatory header structure has historically imposed a significant memory tax on Java applications, particularly those dealing with numerous small objects.
Traditional HotSpot JVM objects carry substantial overhead through their headers, consisting of a 64-bit mark word and a 32-bit compressed class word. The mark word stores instance-specific metadata, including garbage collection age and forwarding pointers, stable identity hash codes, and lock/monitor information. The class word contains a compressed pointer to class metadata in metaspace.
For objects averaging 32-64 bytes, which are common in real-world applications, this 12-byte header represents approximately 20% overhead.
Compact Object Headers solve this by ingeniously compressing the class pointer from 32 to 22 bits and merging it with the mark word into a single 64-bit structure:
Testing demonstrates compelling improvements across various workloads. SPECjbb2015 shows 22% less heap usage and 8% faster execution, while Amazon’s production workloads experienced up to 30% CPU reduction across hundreds of services. Garbage collection performance improves significantly with a 15% reduction in collection frequency for both G1 and Parallel collectors. JSON parsing benchmarks reveal a 10% reduction in execution time, and throughput overhead is capped at 5% in worst-case scenarios, with many workloads showing net gains.
The improvements compound in memory-constrained environments, such as edge computing and serverless platforms, where efficient memory utilization directly impacts deployment density and costs.
Enabling Compact Object Headers in Java 25 requires adding a single JVM flag:
Java 24 (Experimental—requires JEP 450)
java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders MyApp
Java 25 (Integrated—JEP 519)
java -XX:+UseCompactObjectHeaders MyApp
The feature works transparently with existing code on x64 and AArch64 platforms. Applications see immediate benefits without modification, though certain configurations face restrictions. Developers cannot combine compact headers with -XX:-UseCompressedClassPointers (deprecated) or legacy stack locking (also deprecated). ZGC support on x64 remains under development.
The implementation achieves compression through several technical breakthroughs. The 22-bit class pointer supports approximately 4 million unique classes, far exceeding any realistic application requirement. This reduction from 32 bits saves critical header space while maintaining practical limits.
JEP 519 represents the first integrated feature from Project Lilliput, OpenJDK’s initiative to minimize object memory overhead. The project’s journey illustrates careful engineering, beginning with the introduction of Object Monitor Tables infrastructure in JDK 22, followed by experimental compact headers via JEP 450 in JDK 24 (March 2025), and culminating in full integration via JEP 519 in JDK 25 (September 2025).
Amazon’s engineering teams have extensively validated compact headers across diverse workloads. They successfully backported the feature to JDK 17 and 21, deployed it across hundreds of production services, and measured consistent efficiency gains without regressions. This real-world validation influenced the decision to integrate the feature into JDK 25 and provides confidence for organizations considering the adoption of this integrated feature.
The memory efficiency improvements directly impact modern cloud deployments. Container density increases as applications require less memory per instance, allowing higher application density per host and reducing infrastructure costs. Cache utilization improves due to smaller objects fitting better in CPU caches. Latency becomes more predictable as reduced GC pressure creates more consistent response times. These benefits compound across microservices architectures where numerous small services benefit simultaneously.
These improvements prove particularly valuable in cost-sensitive environments, where memory efficiency directly translates to operational savings.
For teams running Java applications with many small objects, which includes virtually all modern Java workloads, JEP 519 offers a rare opportunity: substantial performance improvements through a simple configuration change. The feature’s integration into Java 25 signals its readiness for widespread adoption.
