Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Java 25’s -XX:+UseCompactObjectHeaders option shrinks HotSpot object headers, but the amount saved by an application depends on its object mix. Oracle documents a header reduction from 96 or 128 bits to 64 bits; a September 2026 sample benchmark reported about 15.95 bytes less per OrderLine-shaped instance, including its two owned strings. That sample is not a promise of equivalent whole-application heap savings.
What Compact Object Headers change
A Java object has a header that carries runtime information. Oracle’s Java SE 25 GC Tuning Guide documents Compact Object Headers as reducing that header from 96 or 128 bits to 64 bits. In raw terms, that is four bytes for a 12-byte header or eight bytes for a 16-byte header.
That arithmetic describes the header, not the total size of every object or the application’s heap. Fields, references, arrays, object alignment, and the particular objects that remain live all affect the result. Multiplying four or eight bytes by an object count therefore does not establish how much a real application’s heap will shrink.
Recommended Free Tools
How to enable the option in JDK 25
Compact Object Headers are disabled by default in JDK 25. Add this JVM option to the application’s launch command to enable them:
-XX:+UseCompactObjectHeadersIn JDK 25, this is a product option; it does not require -XX:+UnlockExperimentalVMOptions. The option was experimental in JDK 24. For example, a Java launcher command can include it alongside the application’s existing heap settings:
java -XX:+UseCompactObjectHeaders -Xms4g -Xmx4g -jar app.jarOracle also supplies two additional CDS archives, classes_coh.jsa and classes_nocoops_coh.jsa, to support equivalent startup performance when the feature is enabled. Follow the archive and startup configuration guidance for the particular JDK distribution and deployment rather than assuming that changing the flag alone settles every CDS detail.
Rank #2
What the published OrderLine example reported
Avaneesh Yadav’s September 29, 2026 article at BuildingAI.in reports runs using Temurin JDK 25.0.3, fixed 4 GiB initial and maximum heap settings, and the same sample program with compact headers disabled and enabled.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →| Reported case | Without compact headers | With compact headers |
|---|---|---|
| First run, bytes per OrderLine-shaped instance | 164.19 | 148.25 |
| Repeat run, bytes per OrderLine-shaped instance | 164.20 | 148.21 |
Those figures imply a difference of roughly 15.95 bytes per measured instance. The example counts three heap objects together—the OrderLine DTO and two owned Strings—so this is a sample-specific aggregate, not a finding that each Java object saves 15.95 bytes. The figures are author-reported, not independently reproduced here. The article also describes a primitives-only variant, but does not provide its full output in the reported material, so no result for that case can be stated.
How to tell whether your application benefits
Oracle says the feature reduces Java heap footprint and potentially provides performance benefits. It does not establish a universal application-wide percentage or guarantee faster execution. A useful comparison changes only the header option while keeping the rest of the test as consistent as possible.
- Check applicability. Oracle documents a limit of four million different loaded classes when compact headers are enabled. Applications that generate or load very large numbers of classes should validate their class-loading behavior against this constraint.
- Hold the test conditions steady. Use the same application version, JDK vendor and build, machine, heap sizing, garbage collector, inputs, and run procedure in both configurations. Toggle only the compact-header flag.
- Measure memory and performance. Compare live heap or retained object sizes along with throughput and latency. Repeat runs, and use representative workloads and object shapes; object-header savings are only one component of an object’s footprint.
- Validate startup configuration. Check the CDS setup and archive behavior used by the deployed runtime when comparing startup as well as steady-state results.
- Roll out based on evidence. Test with representative production-like traffic and monitor memory, latency, and throughput before treating the change as beneficial for a broader deployment.
When the flag is worth considering
The option is most compelling to evaluate when an application retains many objects and heap footprint is an important constraint. The documented reduction in header size gives a reason to test; the actual value depends on the workload’s live object graph. If the application is dominated by other memory costs, or its performance changes unfavorably, the smaller header alone may not make the setting worthwhile.
Rank #4
The evidence supports a specific conclusion: JDK 25 provides a straightforward flag that makes HotSpot object headers smaller, and a published sample reports a measurable reduction for its combined DTO-and-strings case. It does not support promising a fixed heap reduction or performance gain for every Java application.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
