Java 25's Compact Object Headers: I Measured the Real Savings So You Don't Have To

I also ran a second, deliberately simpler variant — a primitives-only class with no nested objects, so exactly one heap object is allocated per instance, isolating the header effect from any nested-string savings:

// ObjectHeaderBenchmarkSimple.java — full source, companion isolation test
import java.util.ArrayList;
import java.util.List;

public class ObjectHeaderBenchmarkSimple {

    static final class Metric {
        final long id;
        final int count;
        final double value;
        final boolean active;
        final long timestampEpoch;

        Metric(long id, int count, double value, boolean active, long timestampEpoch) {
            this.id = id;
            this.count = count;
            this.value = value;
            this.active = active;
            this.timestampEpoch = timestampEpoch;
        }
    }

    static long usedHeapBytes() {
        Runtime rt = Runtime.getRuntime();
        return rt.totalMemory() - rt.freeMemory();
    }

    static void settle() throws InterruptedException {
        for (int i = 0; i < 3; i++) { System.gc(); Thread.sleep(150); }
    }

    public static void main(String[] args) throws Exception {
        int n = args.length > 0 ? Integer.parseInt(args[0]) : 8_000_000;

        settle();
        long before = usedHeapBytes();

        List<Metric> items = new ArrayList<>(n);
        for (int i = 0; i < n; i++) {
            items.add(new Metric(i, i % 50, 9.99 + (i % 500), (i % 3 == 0), 1_700_000_000L + i));
        }

        settle();
        long after = usedHeapBytes();
        long delta = after - before;

        System.out.println("N (Metric instances, single heap object each) = " + n);
        System.out.println("Delta                                          = " + delta + " bytes");
        System.out.println("Bytes per instance                             = " + String.format("%.2f", (double) delta / n));

        if (items.isEmpty()) throw new AssertionError("unreachable, keeps 'items' live");
    }
}

Actual console output — default:

N (Metric instances, single heap object each) = 8000000
Delta                                          = 417675096 bytes
Bytes per instance                             = 52.21

Actual console output — -XX:+UseCompactObjectHeaders:

N (Metric instances, single heap object each) = 8000000
Delta                                          = 353674232 bytes
Bytes per instance                             = 44.21

Why My Numbers Don't Match "4 Bytes Per Object"

The header arithmetic is 12 bytes down to 8, so 4 bytes per object (the JEPs themselves report savings as percentages, such as the 22% less heap space above). My clean, single-heap-object benchmark measured 8 bytes saved, not 4 — double the arithmetic. That's not a benchmarking error; it's alignment.

The JVM rounds every object's total size up to an 8-byte boundary. Shrinking the header by 4 bytes doesn't always shrink the rounded object size by exactly 4 bytes — it depends on where the unpadded size falls relative to that boundary. My Metric class's field layout happens to land such that the smaller header pushes the whole object across an alignment boundary, saving a full 8-byte slot instead of a partial 4. A class with different field ordering or count could just as easily save 0 bytes if its padding already absorbed the difference, or exactly 4 if it lands differently.

This is the actual lesson: "4 bytes per object" is the header arithmetic, not what any given class saves — your specific classes will save 0, 4, or 8 bytes depending on their field layout and alignment, not a uniform 4. Don't take either number — mine or the JEP's — as what your classes will show. Measure your own shapes the way I measured mine; the benchmark above is under 70 lines and runs in seconds.

The OrderLine result (≈15.95 bytes across 5 heap objects: the DTO, its two Strings and the two byte[] arrays that hold their characters, so ≈3.2 bytes/object on average) sits below the single-class numbers precisely because it's a blend of five layouts, each hitting the alignment boundary differently. The sizes add up exactly: with the 12-byte header, 56 (OrderLine) + 24 + 24 (the Strings) + 32 + 24 (the byte[] arrays) + 4 (the list slot) = 164 bytes; with the 8-byte header, 48 + 24 + 24 + 24 + 24 + 4 = 148 bytes.

What This Means at Spring Boot Scale

Scope this honestly: it shrinks object header overhead specifically. It is not a "your app uses 30% less memory" claim, and anyone telling you that from this JEP alone is overselling it.

But translated to a realistic number: a service holding 20 million cached order-line objects (a plausible in-memory cache or a large batch-processing window) at the measured ≈15.95 bytes/instance saving:

20,000,000 × 15.95 bytes ≈ 319,000,000 bytes ≈ 304 MiB saved

That's real heap headroom recovered from a one-line JVM flag change, with zero code changes, zero redeploy risk beyond the flag itself. For a heap-constrained service running close to its container memory limit, 300+ MiB is the difference between comfortable and paging.

The effect compounds with anything that holds large object graphs: JPA persistence contexts with big result sets, in-memory caches (Caffeine, Guava), large List<T>/Map<K,V> collections, and — relevant to this site specifically — the document chunks and embeddings held in memory by a RAG pipeline built with Spring AI.

Pros and Cons

When to Use It vs. When Not To

Use it when:

• Your workload is object-header-heavy — lots of small objects (DTOs, entities, value objects, boxed wrappers), not a few large ones. Header overhead is proportionally biggest exactly where you have the most instances.
• You're memory-constrained — a container memory limit you're pushing against, or GC pause pressure from a large heap — and want a free lever to try before reaching for an architecture change.
• You're already on JDK 25+ with no low-level JNI/Unsafe dependency that touches object layout directly.
• You can canary it — you have the observability and rollback path to validate before a fleet-wide rollout (see below). This is what makes it low-risk to even experiment with.

Don't enable this yet if:

• You depend on native code (JNI) or a library that inspects raw object header bytes directly — anything hand-rolled that assumes the pre-519 12-byte layout can misbehave. That is my own caution: the risks the JEPs list are future header-bit needs (four bits are reserved for Project Valhalla) and JVMCI, where compact headers are disabled.
• You use a serialization library with header-layout assumptions baked in (rare, but some low-level off-heap/unsafe-based tools exist). Check your dependency list, don't assume.
• Your objects are already large — a service dominated by big byte[] buffers or large arrays won't feel this; the header is a small fraction of an already-large object, so the win is diluted to near-zero.
• You haven't measured your own workload yet. The alignment effect above means your savings could be 0 bytes for some classes — verify before you write "we cut memory by X%" in a postmortem.
• You're on a JDK older than 25, or a vendor build that hasn't backported JEP 519 — check java -XX:+PrintFlagsFinal -version | grep CompactObjectHeaders before assuming it's available.

How to try it safely: flip the flag on one canary instance behind your existing traffic split, watch GC pause times and heap-used metrics in your existing observability stack (the same OpenTelemetry setup you already have) for a few days, then roll forward. It's a JVM flag, not a code change — rollback is instant.

An Illustrative Scenario: The Nightly Reconciliation Job

Here is how the numbers could matter, using the same OrderLine shape from the benchmark above. This is a hypothetical, not a report of a job I ran: the row count and the container limit are assumptions chosen to show the arithmetic.

Picture a nightly batch job that reconciles the day's orders: it loads every order line from the last 24 hours into memory — say 12 million rows on a busy day — builds an in-memory index keyed by SKU, cross-checks it against a warehouse feed, and writes discrepancies back. The whole job runs inside one JVM, holding all 12 million OrderLine-shaped objects live at once because the cross-check needs random access across the full set, not a streaming pass.

Before: at the measured 164.19 bytes/instance, 12 million rows costs ≈1.83 GiB just for this in-memory index — before the job's own working set, before the warehouse-feed data it's comparing against, before JVM/GC overhead on top.

After enabling -XX:+UseCompactObjectHeaders: at 148.25 bytes/instance, the same 12 million rows costs ≈1.66 GiB — ≈182 MiB recovered, with the job's code completely unchanged.

In a scenario like this, 182 MiB could be the difference between the job fitting comfortably inside its container's memory limit and occasionally tripping the OOM killer on the busiest reconciliation nights — the nights with the most orders, which are exactly the nights you can least afford the job to fail. The fix here isn't "rewrite the index to be more memory-efficient" (a real project, with real risk) — it's one flag on the job's JVM invocation, validated on a few non-critical runs first, then rolled into the production cron entry.

This is the pattern worth internalizing: this JEP doesn't fix a bad architecture, but it gives you real, measurable headroom on an unchanged architecture — which is exactly the kind of low-risk win worth taking before reaching for a bigger redesign.

Try It Yourself

Both full source files are above, unmodified from what I actually ran — save either one, verbatim, into a file matching its class name (ObjectHeaderBenchmark.java / ObjectHeaderBenchmarkSimple.java), and run:

java -Xms4g -Xmx4g -XX:-UseCompactObjectHeaders ObjectHeaderBenchmark.java 8000000
java -Xms4g -Xmx4g -XX:+UseCompactObjectHeaders ObjectHeaderBenchmark.java 8000000

No build tool, no dependencies — single-file source launch runs it directly. Then swap the OrderLine field list for your own entity/DTO shape and re-run. That's the only number worth putting in a capacity-planning doc — not mine, not the JEP's, yours.

Resources

• JEP 519: Compact Object Headers — the primary source; read the "Risks and Assumptions" section before enabling this in production
• JEP 534: Compact Object Headers by Default — confirms this becomes the JDK 27 default, so this is worth understanding now rather than when it's forced on you
• JEP Index — for tracking what else is landing in the JDK 26/27 cycle
• My Java Developer Roadmap 2026 and Structured Concurrency in Java 24 if you want the rest of what's changed in modern Java

Related reading

• Java 21 Virtual Threads: A Practical Guide for Spring Boot Developers — another JVM change that matters for Spring Boot services.
• 10 Spring Boot Mistakes That Silently Kill Production Apps — common production problems in Spring Boot apps.
• Your Spring Boot App Starts in 3 Seconds. With GraalVM Native, It's 80ms. — a different route to a lighter Spring Boot service.

Ran these benchmarks yourself and got different numbers? That's expected — send me your class shape and results. Find me on LinkedIn or browse the full buildingai.in blog.