Java 27: The Under-the-Hood Efficiency Release

The feature set for JDK 27 is officially frozen. Having entered Rampdown Phase One, the release is on track for General Availability on September 15, 2026.

For developers tracking the language syntax, Java 27 might initially look like a quiet release. It contains only nine JDK Enhancement Proposals (JEPs), and more than half of those are re-submitted previews or incubators. If you are waiting for Structured Concurrency (JEP 533) to finally cross the finish line, you will have to keep waiting; it is now on its seventh preview. The Vector API (JEP 537) is on its twelfth incubator, seemingly a permanent resident of the JDK experimental wing.

Yet, dismissing Java 27 as a minor update misses the point. This release delivers some of the most significant under-the-hood runtime optimizations the JVM has seen in years. By making compact object headers the default and expanding the reach of the G1 garbage collector, Java 27 targets the operational realities of modern, containerized deployments. It is a release designed to lower cloud infrastructure bills without requiring a single line of code to be rewritten.

Compact Object Headers by Default (JEP 534)

Every Java object stored in memory carries an overhead tax in the form of an object header. Historically, on 64-bit architectures, this header consumed 96 bits (12 bytes), split between a 64-bit Mark Word (handling identity hash codes, GC age, and locking) and a 32-bit Class Word (pointing to class metadata).

JEP 534 changes the default layout, compressing this header down to 64 bits (8 bytes). It achieves this by merging the Mark Word and Class Word into a single 64-bit structure. The new layout allocates:

• 22 bits for a compressed class pointer
• 31 bits for the identity hash code
• 4 bits reserved for future Project Valhalla value classes
• 4 bits for GC generational age
• 2 bits for locking states
• 1 bit for self-forwarding during garbage collection

Saving 4 bytes per object might sound trivial, but across a heap containing millions of small objects (such as nodes in a syntax tree, JSON maps, or database entities), the cumulative savings are massive.

xychart-beta
title "SPECjbb2015 Resource Reductions with Compact Object Headers"
x-axis ["Heap Space", "CPU Time", "GC Frequency"]
y-axis "Reduction (%)" 0 --> 25
bar [22, 8, 15]

According to benchmarks run by Oracle, Amazon, and SAP, enabling compact object headers by default reduces heap usage in the SPECjbb2015 benchmark by 22% and CPU time by 8%. Because the heap footprint is smaller, the garbage collector has less work to do, resulting in a 15% reduction in GC cycles. A highly parallel JSON parser benchmark also showed a 10% throughput improvement due to better CPU cache locality.

For operations teams, this translates directly to higher deployment density. You can pack more application instances onto the same hardware without hitting memory limits. If you run into edge-case compatibility issues, you can temporarily revert to the old layout using the -XX:-UseCompactObjectHeaders flag, though this option is slated for deprecation and eventual removal.

G1 Everywhere (JEP 523)

Since Java 9, the Garbage-First (G1) collector has been the default for most server environments. However, the JVM maintained a historical exception: if the host environment had only one CPU or less than 1792 MB of RAM, it quietly fell back to the single-threaded Serial Garbage Collector. At the time, G1's internal synchronization and native memory footprint were deemed too heavy for small-footprint environments.

Java 27 eliminates this fallback. G1 is now the default garbage collector across all environments, regardless of CPU count or memory constraints.

This shift is made possible by incremental improvements to G1 over recent releases, notably JEP 522, which reduced synchronization overhead. G1's native memory consumption has also been optimized to match the low footprint of the Serial collector. For developers deploying microservices in small Kubernetes pods (e.g., 0.5 CPU and 1 GB RAM limits), this change ensures your small instances benefit from G1's low-latency, multi-threaded compaction algorithms, avoiding the stop-the-world latency spikes typical of the Serial collector.

JFR In-Process Data Redaction (JEP 536)

JDK Flight Recorder (JFR) is an invaluable tool for production diagnostics, but it has long carried a security risk. JFR records system properties, environment variables, and command-line arguments. In modern cloud environments, these often contain sensitive credentials, database passwords, or API tokens.

JEP 536 introduces in-process data redaction. JFR now automatically scans and masks sensitive data before it is written to the .jfr file, ensuring secrets never leave the JVM process boundary. By default, JFR applies case-insensitive glob patterns to redact values associated with keys like *password*, *token*, *secret*, *private*key*, and *credential*.

Developers can customize this behavior using the -XX:FlightRecorderOptions flag. For example, to redact a custom property and mask credentials in a URL argument, you can run:

java -XX:FlightRecorderOptions='redact-key=confidential,redact-argument=https://*:*@*' \
     -XX:StartFlightRecording:filename=dump.jfr \
     -Dconfidential=MY_SECRET \
     -jar application.jar https://user:pass@example.com/login

When inspecting the resulting JFR file using jfr print, the sensitive values will appear as [REDACTED], protecting credentials from being exposed to developers or log-aggregation tools.

Post-Quantum Cryptography and Performance Gains

Security in the quantum era is another major focus of this release. JEP 527 introduces post-quantum hybrid key exchange schemes for TLS 1.3. These schemes combine traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) with the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM).

The JDK supports three hybrid schemes:

• X25519MLKEM768
• SecP256r1MLKEM768
• SecP384r1MLKEM1024

Because post-quantum cryptographic algorithms are computationally expensive, the OpenJDK team optimized the underlying SHA-3 intrinsics for AVX-512 enabled CPUs in Build 25. These hardware-level optimizations yield dramatic performance improvements for ML-KEM and ML-DSA operations:

• ML-KEM Key Generation: +48%
• ML-KEM Decapsulation: +47%
• ML-KEM Encapsulation: +46%
• ML-DSA Key Generation: +60%
• ML-DSA Verification: +74%

These optimizations ensure that adopting quantum-resistant TLS 1.3 does not result in a severe performance penalty for secure network communications.

Deprecations and Removals

As the platform evolves, older experimental features are being pruned. The most notable removal in Java 27 is the JVM Compiler Interface (JVMCI).

JVMCI was an experimental API that allowed JIT compilers written in Java (like Graal) to integrate with HotSpot. After a decade of maintenance, the JDK maintainers concluded that the testing overhead outweighed the benefits for the broader ecosystem. Projects relying on JVMCI or the Graal JIT compiler inside the stock OpenJDK will need to maintain their own downstream builds or remain on older JDK releases.

Additionally, the obsolete UseCompressedClassPointers flag has been removed, and the rarely used ffdhe6144 and ffdhe8192 groups have been dropped from the default TLS named groups to conserve host resources.

The Verdict

Java 27 proves that a release does not need flashy new syntax to be a compelling upgrade. The default activation of compact object headers and the expansion of G1 to small instances offer immediate, tangible resource savings for containerized applications. Combined with built-in JFR redaction and optimized post-quantum cryptography, Java 27 is a highly practical release focused on security, efficiency, and operational stability.