Two days after Oracle shipped JDK 27 on September 15, 2026, two of its nine JEPs stand out for anyone running Java in production: object headers on every single object in the JVM just got smaller, and the garbage collector that runs when nobody configures one just changed. Neither requires a line of application code. Both change the memory and throughput profile of every Spring Boot service, Jakarta EE application, and batch job that upgrades.

This guide walks through JEP 534 (Compact Object Headers by Default) and JEP 523 (G1 as the Default Garbage Collector in All Environments) in technical depth: what changed, why it was safe to change now, how to verify it on your own workloads, and what it means specifically for Spring Boot teams running in containers.

What Shipped in JDK 27

JDK 27 is a short-term, non-LTS release — Oracle will support it only until March 2027, when JDK 28 supersedes it. The current Long-Term Support release remains JDK 25 (released September 2025). That distinction matters for adoption planning, and we come back to it below. JDK 27 delivered nine JEPs in total:

JEP	Title	Status
523	Make G1 the Default Garbage Collector in All Environments	Final
527	Post-Quantum Hybrid Key Exchange for TLS 1.3	Final
534	Compact Object Headers by Default	Final
531	Lazy Constants	Third Preview
532	Primitive Types in Patterns, `instanceof`, and `switch`	Fifth Preview
533	Structured Concurrency	Seventh Preview
538	PEM Encodings of Cryptographic Objects	Third Preview
536	JFR In-Process Data Redaction	New
537	Vector API	12th Incubator

The preview features (Structured Concurrency, Lazy Constants, primitive patterns) get plenty of blog coverage already because they change how you write code. JEP 523 and JEP 534 get less attention precisely because they don’t touch your source — but for a fleet of containerized Spring Boot services, they are arguably the two changes with the widest blast radius in this release.

JEP 534: Compact Object Headers by Default

The problem with a 96-bit header

Every object on the Java heap carries a header the application never sees. On a 64-bit HotSpot JVM with compressed class pointers (the default for heaps under roughly 32 GB), that header has historically been 96 bits (12 bytes), split into two words:

Mark word (64 bits) — a 31-bit identity hash code, 4 bits of GC age, 2 lock-state tag bits, and 27 bits that simply go unused.
Klass word (32 bits) — a compressed pointer into the class metadata space, identifying the object’s type.

For small, field-light objects — think a JPA entity wrapping a handful of primitives, a DTO, a record, or a boxed Long — that 12-byte header can be a large fraction of the object’s total footprint. A Spring Boot application that loads hundreds of thousands of entities, DTOs, and cache entries pays this tax on every single one.

How compact headers work

JEP 534 makes default what JEP 519 shipped as a production-ready opt-in feature in JDK 25: the mark word and klass word merge into a single 64-bit header. The key trick is compressing the class pointer further, from 32 bits down to 22 bits, by indexing the 4 GB class-metadata space in 1,024-byte-aligned blocks instead of individual bytes (4 GB ÷ 1,024 bytes = 2²² blocks). That frees enough bits to repack the header as:

22-bit compressed class pointer
31-bit identity hash code
4 bits reserved for Project Valhalla
4 bits of GC age
1 self-forwarding tag bit (used during garbage collection when an object is relocated)
2 lock-state tag bits

Diagram comparing the standard 96-bit Java object header layout to the JDK 27 default 64-bit compact object header layout, showing the mark word and klass pointer merging — Standard 96-bit header vs. the JDK 27 default 64-bit compact header.

From experimental to default: a three-release rollout

Oracle didn’t flip this default overnight. It followed OpenJDK’s usual cautious path:

Release	JEP	Status	Flag
JDK 24	JEP 450	Experimental	`-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders`
JDK 25	JEP 519	Production-ready, opt-in	`-XX:+UseCompactObjectHeaders`
JDK 27	JEP 534	Default (still overridable)	`-XX:-UseCompactObjectHeaders` to disable

One implementation detail worth knowing if you’re on JDK 26 or later: compact headers require lightweight locking and are incompatible with legacy stack locking, which was removed as a selectable option around the same time. If you rely on very old -XX:-UseBiasedLocking-era tuning flags from pre-JDK-15 cargo-culted JVM arguments, this is a good moment to clean those up.

Real-world numbers

Because JEP 519 has been production-ready since JDK 25, there’s more than a year of field data behind this default flip. Figures reported by early adopters and cited in OpenJDK’s own SPECjbb2015-based testing include:

~22% heap reduction and ~8% CPU time reduction in OpenJDK’s SPECjbb2015 benchmark runs.
Amazon has reported running compact headers across hundreds of internal production services, citing roughly 8–11% additional throughput from better CPU-cache locality (smaller objects mean more of them fit in a cache line).
SAP ships compact headers as the default in SapMachine, its OpenJDK distribution, and reports single-digit-to-low-teens throughput gains alongside the heap savings.

Treat these as vendor-reported, workload-dependent figures rather than a guarantee — object-header savings scale with how many small objects your application allocates, not with raw heap size. A service dominated by a few large byte arrays will see far less benefit than one that allocates millions of small entities and DTOs per minute.

Compatibility considerations

JNI and native code. Any native library or agent that assumes a fixed header layout or hand-parses object headers (rather than going through the standard JNI functions) is the highest-risk area. Audit before rolling out broadly.
Serialization and low-level tooling. Debuggers, profilers, and memory-analysis tools (heap dump analyzers, JOL, async-profiler) that read raw header bytes need versions aware of the compact layout. Recent releases of the mainstream tools already support it.
Very large heaps. Compact headers depend on compressed class pointers, which are the default for heaps under roughly 32 GB (extendable further with a larger object-alignment value). If you run uncompressed-oops JVMs on huge heaps, verify compressed class pointers are still active before assuming you get the benefit.

JEP 523: G1 as the Default Garbage Collector Everywhere

The old “server-class machine” heuristic

G1 has been the default garbage collector on “server-class” machines since JEP 248 shipped in JDK 9. But “server-class” was a specific, easy-to-miss definition: 2 or more CPUs and roughly 1,792 MB (≈1.75 GB) or more of physical memory. Anything below that threshold — a single-vCPU container, a small CI runner, a serverless function with a tight memory allocation, a single-board device — silently fell back to the Serial collector instead.

That heuristic made sense in 2017, when G1’s baseline memory footprint and single-threaded throughput were meaningfully worse than Serial’s. It stopped making sense as G1 picked up years of tuning, including throughput work like JEP 522’s synchronization reductions, which OpenJDK’s own JEP 523 text describes as bringing G1’s maximum throughput “close to that of Serial” while keeping G1’s substantially better worst-case pause times.

Flow diagram comparing the old server-class heuristic for default garbage collector selection before JDK 27 against the new always-G1 default behavior in JDK 27 under JEP 523 — Default GC selection before and after JEP 523.

What actually changes

As of JDK 27, if you don’t pass a -XX:+Use…GC flag, the JVM always selects G1 — full stop, regardless of CPU count or memory. The JEP’s own risk section is candid about this: some workloads in genuinely constrained environments will still perform best on Serial, and that option remains fully available, just no longer automatic.

The practical implication for cloud-native teams: if you run small containers (a common pattern for microservices with tight resource requests, e.g. 1 vCPU / 512–768 MB in Kubernetes), you may have been running on Serial GC this whole time without anyone deciding that on purpose. On JDK 27, those same containers get G1 by default, with its incremental, mostly-concurrent collection cycles and materially better worst-case pause times — at a small cost in baseline memory and CPU overhead compared to Serial.

When Serial GC is still the right call

Serial remains a legitimate, explicit choice for:

Extremely short-lived processes (CLI tools, AWS Lambda cold starts under ~100–200 MB) where G1’s setup cost outweighs any pause-time benefit.
Single-threaded batch jobs with predictable, small heaps where you’ve already measured Serial performing as well or better.
Environments where absolute minimum memory footprint matters more than pause-time consistency.

Select it explicitly rather than relying on an implicit heuristic:

java -XX:+UseSerialGC -jar app.jar

Why This Matters for Spring Boot and Cloud-Native Java

Both JEPs target exactly the deployment pattern most Spring Boot teams already use: containerized services with modest, right-sized resource limits, running object-heavy workloads (Spring Data JPA / Hibernate entities, MapStruct-generated DTOs, Jackson-deserialized request bodies, cached lookup objects).

Container sizing and cost. A 10–22% reduction in live heap size, compounded across a fleet of services, translates directly into either a lower memory request per pod or more headroom before you hit an OOMKilled event under load spikes.
JPA/Hibernate-heavy services benefit most. Entity graphs with many small, field-light objects (one row per entity, one object per DTO mapping) are exactly the shape of workload where per-object header overhead is proportionally largest.
Small containers get a real GC upgrade for free. If your Kubernetes resource requests keep individual pods under the old ~1.75 GB / 2-vCPU threshold — common for right-sized microservices — JEP 523 is the first time many of those pods will run G1 instead of Serial without you touching a Helm chart.

The LTS nuance: you don’t have to wait for JDK 27 in production

Because JDK 27 is a short-term release, many organizations that follow an LTS-only upgrade policy will stay on JDK 25 in production and only use JDK 27 for evaluation, local development, or non-critical services. That’s a reasonable policy — but it means it’s worth knowing that compact object headers are already production-ready on JDK 25 via JEP 519; you can turn them on today with -XX:+UseCompactObjectHeaders without waiting for a JDK 27 or JDK 29 upgrade. G1-by-default is a smaller ask: you can force G1 on any current JDK, LTS or not, with an explicit -XX:+UseG1GC flag, and it’s worth checking today whether your small containers are quietly running Serial.

Practical Implementation: Upgrading and Measuring

1. Get a JDK 27 build

Use Eclipse Temurin, Oracle, Amazon Corretto, or GraalVM CE builds for JDK 27. For local development:

sdk install java 27-tem
sdk use java 27-tem
java -version

2. Bump the Maven or Gradle toolchain

<properties>
    <java.version>27</java.version>
    <maven.compiler.release>27</maven.compiler.release>
</properties>

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(27)
    }
}

Check your Spring Boot version’s supported Java baseline before upgrading — Spring Boot 3.x targets Java 17+ and is generally forward-compatible with newer non-LTS releases, but always confirm against the current Spring Boot release notes before a production rollout.

3. Update the container base image

# Build stage
FROM eclipse-temurin:27-jdk-jammy AS build
WORKDIR /app
COPY . .
RUN ./mvnw -q package -DskipTests

# Runtime stage
FROM eclipse-temurin:27-jre-jammy
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

4. Verify what’s actually active

Don’t assume — confirm which GC and header layout your JVM selected:

java -XX:+PrintFlagsFinal -version | grep -E "UseG1GC|UseSerialGC|UseCompactObjectHeaders"

On JDK 27 with no explicit flags, you should see UseG1GC = true and UseCompactObjectHeaders = true in the output.

5. Benchmark the difference on your own workload

Vendor benchmarks are a starting point, not a substitute for measuring your own service. Two lightweight ways to do it:

GC and heap logging — run the same load test against the old and new JVM and compare:

java -Xlog:gc*:file=gc.log:time,level,tags -jar app.jar

Per-object header inspection with the Java Object Layout (JOL) library, useful for confirming the layout change on a specific entity class:

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.17</version>
</dependency>

import org.openjdk.jol.info.ClassLayout;

public class HeaderCheck {
    public static void main(String[] args) {
        System.out.println(
            ClassLayout.parseInstance(new Object()).toPrintable()
        );
    }
}

Roll the change out to one non-critical service first, compare heap-utilization and GC-pause metrics before and after in your existing observability stack (Micrometer, Prometheus, whatever you already run), and only then expand to the rest of the fleet.

Advantages and Limitations

	Advantages	Limitations
Compact Object Headers	10–22% typical heap reduction; better CPU-cache locality; zero application code changes; can be enabled today on JDK 25 LTS	Highest risk with JNI/native code that assumes header layout; needs lightweight locking (JDK 26+); tooling must support the new layout
G1 by Default	Better worst-case pause times for previously-Serial small containers and CI runners; no configuration needed; Serial remains available by explicit flag	Slightly higher baseline memory/CPU overhead than Serial for genuinely tiny, short-lived processes; JDK 27 itself is short-term, not LTS

Common Mistakes and Pitfalls

Assuming the default applies retroactively. Upgrading the JDK on the build image but not the runtime image (or vice versa) means you’re not actually running JDK 27 in production — verify with java -version inside the running container, not just the Dockerfile.
Skipping the JNI/native-code audit. If your service embeds a native library (image processing, crypto acceleration, a legacy JNI bridge), test it explicitly under compact headers before a fleet-wide rollout.
Comparing benchmarks across different heap shapes. A service dominated by a few large arrays won’t show the same heap savings as one built on millions of small JPA entities — don’t extrapolate published percentages onto a workload with a very different object-size distribution.
Forgetting that JDK 27 is not LTS. Treat it as an evaluation and fast-follow platform, or budget for the JDK 28 upgrade in March 2027, unless your organization is comfortable riding non-LTS releases in production.
Not re-checking old JVM tuning flags. Command lines inherited from JDK 8/11-era tuning guides (explicit -XX:+UseBiasedLocking, hand-picked young-generation sizes tuned for Serial) can interact unpredictably with a newly-default G1 and should be revisited, not carried forward blindly.

Performance and Security Considerations

On the performance side, the combined effect of both JEPs is additive but not strictly linear: a smaller per-object header means more objects fit in the same G1 region and in CPU cache lines, which can modestly improve G1’s own scanning and copying costs on top of the direct heap-size reduction.

JDK 27 also shipped two security-relevant JEPs worth knowing about even though they’re outside this article’s main focus: JEP 527 (Post-Quantum Hybrid Key Exchange for TLS 1.3) adds quantum-resistant key exchange alongside classical algorithms for outbound TLS connections, and JEP 536 (JFR In-Process Data Redaction) strips secrets, tokens, and other sensitive command-line/environment data from Java Flight Recorder recordings before they leave the process — relevant if you ship JFR recordings to a central diagnostics platform.

FAQ

Is JDK 27 a Long-Term Support (LTS) release?

No. JDK 27 is a short-term release, supported by Oracle only until March 2027 when JDK 28 replaces it. The current LTS release is JDK 25 (released September 2025); the next LTS is expected to be JDK 29.

Do I need to change my Spring Boot code to benefit from Compact Object Headers or G1-by-default?

No. Both are JVM-level defaults with no API surface. Upgrading the JDK your application runs on (and rebuilding your container image on a JDK 27 base) is sufficient to pick up both changes.

Can I get Compact Object Headers on Java 25, the current LTS?

Yes. JEP 519 made compact headers production-ready and opt-in starting in JDK 25. Add -XX:+UseCompactObjectHeaders to your JVM arguments; you don’t need JDK 27 to use the feature, only to get it as the default with no flag.

Will Compact Object Headers break my JNI or native-library integration?

It can, if that native code assumes a fixed 96-bit header layout instead of going through standard JNI accessor functions. Audit any native dependencies and test explicitly before a broad rollout; this is the single highest-risk compatibility area cited in JEP coverage.

Does G1 becoming the default slow down small containers?

It can add a small amount of baseline memory and CPU overhead compared to Serial GC in genuinely tiny, short-lived processes. For long-running services — the vast majority of Spring Boot deployments — G1’s better worst-case pause times generally outweigh that cost. Measure your specific workload, and fall back to -XX:+UseSerialGC explicitly if it doesn’t.

What heap savings should I realistically expect in a typical Spring Boot service?

Reported figures cluster around 10–22% heap reduction, but this scales with how many small objects (entities, DTOs, cached records) your service allocates relative to large arrays or buffers. Measure your own workload with GC logging or JOL rather than assuming a published number applies directly.

Conclusion

JEP 534 and JEP 523 are the kind of changes that don’t show up in a “what’s new” tweet thread but quietly improve the baseline for every JVM workload that upgrades: smaller objects, fewer surprise Serial-GC containers, and no application code to change. For Spring Boot teams running object-heavy, containerized services, they’re worth testing now — either by trying JDK 27 directly, or by enabling -XX:+UseCompactObjectHeaders and checking your actual GC selection on the JDK 25 LTS you’re probably already running. Measure on your own workload, watch the JNI/native-code edge cases, and remember that JDK 27 itself is a short-term release — a good vehicle for evaluation, not necessarily for a permanent production pin.

Resources & References

Official documentation and specifications

JEP 523: Make G1 the Default Garbage Collector in All Environments — OpenJDK. Primary specification for the GC default change: goal, the old server-class heuristic from JEP 248, motivation, and risk notes.
JEP 534: Compact Object Headers by Default — OpenJDK. Primary specification for making compact headers the default in JDK 27, building on JEP 450 and JEP 519.
JEP 525: Structured Concurrency (Sixth Preview) — OpenJDK. Referenced for JDK 27 release context and the ongoing preview cycle of related concurrency JEPs.
JEP 248: Make G1 the Default Garbage Collector — OpenJDK. The original JDK 9 JEP that JEP 523 extends.
The Arrival of Java 27 — Oracle (Java Platform Group). Official release announcement used for the JDK 27 release date, full JEP list, and short-term support timeline (through March 2027).

Technical publications and independent analysis

JDK 27: The new features of Java 27 — InfoWorld. Used to cross-check the complete JEP list and final-vs-preview status for JDK 27.
The Arrival of JDK 27 — Inside.java. Used for release-date confirmation and JEP summaries.
Java 27 grows up, makes better choices — The Register. Used for independent analyst commentary on the real-world impact of G1-by-default on containerized deployments, and confirmation of JDK 27’s short-term (non-LTS) status.
Compact Object Headers in Java (JEP 519) — HappyCoders.eu. Used for the detailed bit-layout breakdown of standard vs. compact headers, the class-pointer compression mechanism, and the JDK 24→25→27 flag history.
Compact Object Headers in Production — Java Code Geeks. Used for production adoption figures (Amazon, SAP/SapMachine) and the pre-deployment checklist.
Java 27 – part 1: JEP 523, G1 Becomes the Default Everywhere — Ron’s Tech Blog. Used for the practical breakdown of which deployment environments were affected by the old server-class heuristic.

Visuals

Featured image and in-article diagrams (object header layout comparison, GC default-selection flow) are original graphics created for this article to illustrate JEP 534 and JEP 523.

Java 27

Posts

JDK 27 Compact Object Headers and G1 by Default: A Practical Guide