JDK 27 Released: G1 Default GC, Compact Object Heads, Post-Quantum TLS

Overview

Oracle released JDK 27 on September 15, 2026 (JSR 402), the reference implementation of Java SE 27. This release contains nine JEP-grade enhancements — four preview features, one incubator feature — and several default behavior changes that take effect without code modifications.

JEP Summary

JEP 523 : G1 as Default GC for All Environments (Final) — Faster startup, lower latency

JEP 534 : Compact Object Headers Default (Final) — Object header reduced from 96 to 64 bits

JEP 527 : TLS 1.3 Post-Quantum Hybrid Key Exchange (Final) — Enabled by default, no code changes

JEP 531 : Lazy Constants (Third Preview) — Performance optimization for AI/data apps

JEP 532 : Primitive Type Pattern Matching (Fifth Preview) — switch/instanceof support for int, long, etc.

JEP 533 : Structured Concurrency (Seventh Preview) — Simpler, more reliable concurrent programming

JEP 537 : Vector API (Twelfth Incubator) — Vector acceleration for AI inference/scientific computing

JEP 536 : JFR In-Process Data Sanitization (Final) — Automatic redaction of sensitive data

JEP 538 : PEM Encoding API (Third Preview) — Standardized key/certificate encoding/decoding

G1 as Universal Default GC (JEP 523)

Since JDK 9, G1 was the default only for server-class machines. In memory-constrained environments (small containers, embedded devices, CLI tools), the JVM fell back to Serial GC — a single-threaded collector that causes long Full GC pauses once data volume grows.

Developers often misattribute these pauses to application code when the real culprit is the default GC choice.

JEP 523 makes G1 the default for all environments. Oracle's justification: after years of optimization, G1 now matches or beats Serial GC across all metrics:

Throughput : JDK 27 reduces G1 synchronization overhead (JEP 522), bringing max throughput near Serial levels.

Latency : G1 uses incremental old-generation collection instead of Serial's full collection, yielding consistently lower max pause times.

Native Memory : Recent versions lowered G1's native memory footprint to match Serial.

Startup Time : Small-heap startup overhead is no longer noticeable.

Impact : Zero configuration required. Upgrading to JDK 27 automatically switches small-heap workloads from Serial to G1, eliminating pause issues. Developers needing extreme startup speed can still explicitly request Serial GC via -XX:+UseSerialGC.

Compact Object Headers Default (JEP 534)

Traditional Object Header Layout

On 64-bit JVMs, each object header comprises:

Mark Word : 64 bits (hash code, GC age, lock state)

Klass Pointer : 64 bits (pointer to class metadata)

Total: 96 bits (12 bytes) . A minimal new Object() occupies 16 bytes (12-byte header + 4-byte alignment padding).

Compression Mechanism

JEP 534 compresses the Klass Pointer from 64 to 32 bits , reducing the total header to 64 bits (8 bytes) . This works because Metaspace typically stays under 4 GB, so a 32-bit index suffices instead of a full 64-bit address.

Result : new Object() drops from 16 to 12 bytes (8-byte header + 4-byte padding) — a 25% heap reduction .

Benefits

Same memory holds more objects

Reduced GC pressure (fewer objects to scan/collect)

Better data locality (denser objects improve CPU cache hit rates)

Compact headers were optional since JDK 24; after two releases of validation, JDK 27 enables them by default. No action required — upgrade and benefit.

TLS 1.3 Post-Quantum Hybrid Key Exchange (JEP 527)

"Quantum computing is far off — why care now?"

Attackers employ "store now, decrypt later": capture encrypted traffic today, decrypt when quantum computers mature. Post-quantum protection is urgent, not futuristic.

Hybrid Approach

JDK 27 adds hybrid key-exchange algorithms combining a quantum-resistant algorithm with a classical one. Even if the classical half is broken, the quantum-resistant half remains secure.

New algorithms (priority order):

X25519MLKEM768 (highest priority in default group list)

SecP256r1MLKEM768

SecP384r1MLKEM1024

Zero-Code Adoption

Applications using javax.net.ssl APIs automatically gain post-quantum protection upon upgrading to JDK 27 — no code changes needed.

Lazy Constants (JEP 531, Third Preview)

Problem

Traditional static final constants initialize at class-load time. Expensive initializations (database config loading, large file parsing, ML model initialization) slow startup.

Solution

Lazy constants defer initialization until first use while the JVM treats them as true constants for optimization — runtime performance equals final fields.

// Traditional: initializes at class load
public static final List<Config> CONFIGS = loadFromDatabase();

// Lazy constant: initializes on first access
private static final LazyConstant<List<Config>> CONFIGS = 
    LazyConstant.of(() -> loadFromDatabase());

public List<Config> getConfigs() {
    return CONFIGS.get(); // first call initializes, subsequent calls use cached value
}

AI Relevance

AI workloads frequently involve expensive read-only data: model weights, tokenizer vocabularies, vector indexes. Lazy constants enable on-demand loading without sacrificing steady-state performance.

Primitive Type Pattern Matching (JEP 532, Fifth Preview)

Pain Point

Prior switch only matched reference types (String, enum, wrapper classes). Matching int required legacy switch-case, losing pattern-matching expressiveness.

Enhancement

JEP 532 permits primitive types in pattern matching, instanceof, and switch. It also strengthens switch exhaustiveness checking, catching more errors at compile time.

// Legacy int matching
switch (statusCode) {
    case 200: return "OK";
    case 404: return "Not Found";
    default: return "Unknown";
}

// JDK 27 preview: pattern matching with primitives
Object obj = getStatusCode();
return switch (obj) {
    case int i when i == 200 -> "OK";
    case int i when i == 404 -> "Not Found";
    case String s -> "String: " + s;
    default -> "Unknown";
};

Structured Concurrency (JEP 533, Seventh Preview)

Traditional Concurrency Issues

// Traditional: two concurrent tasks, messy error handling
Future<User> userFuture = executor.submit(() -> fetchUser(id));
Future<Order> orderFuture = executor.submit(() -> fetchOrder(id));

try {
    User user = userFuture.get();
    Order order = orderFuture.get();
    return new Result(user, order);
} catch (Exception e) {
    // One failed, the other still running — how to cancel?
    // Thread leak?
    throw e;
}

Child task lifecycles aren't bound to the parent. Parent failure leaves children running; child failure leaves parent unaware of how to cancel siblings.

Structured Approach

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Supplier<User> user = scope.fork(() -> fetchUser(id));
    Supplier<Order> order = scope.fork(() -> fetchOrder(id));

    scope.join();           // wait for all children
    scope.throwIfFailed();  // propagate any failure

    return new Result(user.get(), order.get());
}
// Exiting try block auto-closes scope, cancels unfinished children

Core value : Child lifecycles strictly nest within the parent. Parent failure cancels all children; child failure notifies parent. No thread leaks, no orphan tasks.

Vector API (JEP 537, Twelfth Incubator)

Vector API exposes SIMD (Single Instruction, Multiple Data) hardware instructions to Java. On CPUs supporting AVX-512 or ARM SVE, a single instruction processes multiple data elements simultaneously.

For matrix operations and vector similarity calculations common in AI inference, performance gains can be orders of magnitude .

// Vector addition — processes multiple floats per instruction
FloatVector a = FloatVector.fromArray(SPECIES, arr1, i);
FloatVector b = FloatVector.fromArray(SPECIES, arr2, i);
FloatVector c = a.add(b);
c.intoArray(result, i);

Still incubating, but its value for AI/scientific computing is clear.

Other Notable Improvements

JEP 536: JFR In-Process Data Sanitization — JDK Flight Recorder redacts command-line args, environment variables, and system properties before recordings leave the process, preventing accidental secret leakage during production profiling.

ML-KEM/ML-DSA Private Key Encoding Updates — Standardized post-quantum key encoding; X25519 and Ed25519 performance improvements.

JSON Thread Dumps — Thread IDs, thread counts, and process IDs in thread dumps now use JSON numbers, easing monitoring-tool parsing.

jcmd VM.security_properties — New command to inspect active security properties at runtime.

JVMCI Removal — Legacy JVMCI options and features removed; impacts Graal JIT users.

Pros and Cons

Advantages

G1 universal default — Small-heap environments no longer suffer Serial GC pauses; throughput, latency, memory, startup all match or beat Serial.

25% heap reduction via compact headers — More objects per GB, lower GC pressure, better cache locality; large-scale apps benefit directly.

Post-quantum TLS by default — javax.net.ssl users gain quantum-resistant encryption automatically; foundational security upgrade.

Lazy constants for AI/data apps — Expensive read-only data (model weights, vector indexes) loads on demand with final -equivalent runtime performance.

Structured concurrency reliability — Strict lifecycle nesting eliminates thread leaks and orphan tasks.

JFR data sanitization — Production profiling no longer risks exposing secrets.

Caveats

Non-LTS release — Oracle support ends March 2027. Production environments should prefer JDK 25 LTS.

Preview/incubator features require --enable-preview — Lazy constants, primitive pattern matching, structured concurrency, Vector API need explicit flags and may change incompatibly.

JVMCI removed — Projects using Graal JIT (JVMCI-based) must verify compatibility with GraalVM updates.

Compact headers may affect diagnostic tools — Profilers relying on object-header layout may need updates.

Applicability Guidance

Experimentation / learning / personal projects — ✅✅✅ Strongly recommended. Default changes immediately tangible; preview features explorable.

Small-memory containers / embedded — ✅✅✅ Strongly recommended. G1 default + compact headers improve startup and memory.

Large-scale Java applications — ✅✅ Recommended. 25% heap reduction, but evaluate non-LTS risk.

Security-sensitive HTTPS applications — ✅✅✅ Strongly recommended. Post-quantum encryption default, zero code changes.

AI / data-intensive applications — ✅✅ Recommended. Lazy constants + Vector API, but preview features need evaluation.

Long-term stable production — ⚠️ Evaluate carefully. JDK 25 LTS is safer.

Graal JIT dependent projects — ❌ Not recommended. JVMCI removed; await GraalVM alignment.

Conclusion

Is JDK 27 worth upgrading? Worth trying; for production, wait for JDK 28 or JDK 29 LTS.

JDK 27's greatest value lies in three default behavior changes that deliver immediate runtime benefits without any developer action:

G1 as universal default — Faster startup, lower latency automatically.

64-bit object headers — 25% heap reduction automatically.

Post-quantum TLS enabled by default — HTTPS gains quantum-resistant protection automatically.

These are concrete runtime gains, not "preview of a preview."

Among preview features, structured concurrency (if finalized, will transform Java concurrency patterns) and lazy constants (poised to become standard for AI applications) deserve closest attention.

If your production runs on JDK 21 or JDK 25 LTS, no rush to upgrade . But for new projects, test environments, or early exploration of Java's evolution — JDK 27 is worth a spin.

References

JDK 27 Official Download : https://jdk.java.net/27

JEP List : https://openjdk.org/projects/jdk/27/

Oracle Java 27 Announcement : https://www.oracle.com/java/

Inside.java JDK 27 Analysis : https://inside.java/2026/09/15/jdk-27-available/