Performance Improvements in JDK 26

1. Introduction

JDK 26 contains multiple resolved issues and over 1,000 enhancements. A major part of this work focuses on performance across the JDK libraries, garbage collectors, compiler, and runtime.

Some improvements require an API change or a JVM option. Others benefit existing applications as soon as they move to JDK 26. Together, these changes target faster startup, higher throughput, and better scalability.

In this tutorial, we’ll explore the most important performance improvements in JDK 26. We’ll also see how they affect application code and deployment choices.

2. JDK Library Improvements

We’ll start with the changes that very closely relate to application library code.

2.1. Lazy Constants

JEP 526 introduces Lazy Constants as a second preview. The LazyConstant API holds an immutable value that is computed only when it’s first requested.

Before JDK 26, delaying the creation of an expensive object often required a nullable field, a null check, and synchronization. For example, we could initialize a service only when it was first requested:

public final class Application {
    private static Service service;

    static synchronized Service service() {
        if (service == null) {
	    service = new Service();
	}

	return service;
    }

	private static final class Service {}
}

We can now express the same intent directly:

public final class Application {
    private static final LazyConstant<Service> SERVICE = LazyConstant.of(Service::new);
    static Service service() {
        return SERVICE.get();
    }
    private static final class Service {}
}

The first call to get() creates the service. Later calls return the same value. Initialization occurs at most once and remains safe when several threads race to access it. When a lazy constant is stored in a final field, the JVM can optimize repeated access in a way similar to a final constant. This gives us deferred work without permanently paying the usual synchronization cost.

Since this is a preview API, we need preview features at compile time and runtime:

javac --enable-preview --release 26 Application.java
java --enable-preview Application

2.2. Strings, Records, and Cryptography

JDK 26 reduces intermediate allocation and copying inside MemorySegment.getString(). This matters when an application frequently converts native or off-heap data into Java strings. Early benchmarks showed lower latency for all tested sizes, with the largest improvement for short strings.

Generated hashCode() methods for records now receive better type profiling. Record-heavy maps, sets, grouping operations, and deduplication can therefore gain throughput without source changes. The release also optimizes AES, ML-DSA, and elliptic-curve P-256 operations. These changes improve key setup, low-level arithmetic, and hardware-specific execution on supported processors.

There are smaller improvements as well. GZIPInputStream reads single compressed streams more efficiently, while Method.equals() it immediately succeeds when both references point to the same instance. The latter can help dynamic proxies, where method comparisons occur frequently during dispatch.

3. Garbage Collection and Startup Improvements

Garbage collection runs automatically, but it isn’t free. The JVM performs extra work whenever an application changes object references. It also prepares heap structures, classes, and commonly used objects during startup.

JDK 26 reduces both kinds of overhead. It makes G1 reference tracking less expensive, extends ahead-of-time caching to every garbage collector, and avoids preparing an unnecessarily large initial heap.

3.1. Lower G1 Synchronization Overhead

G1 divides the heap into many regions. During a collection, it can reclaim selected regions instead of processing the entire heap.

Objects in different regions can still reference one another. For example, an Order object in one region may reference a Customer object in another. G1 must remember this connection so that it doesn’t reclaim the customer while the order is still reachable.

G1 tracks these changes using a card table. The card table represents the heap as a collection of small areas called cards. When application code changes an object reference, a write barrier marks the corresponding card as dirty.

This write barrier runs for every relevant reference update:

order.setCustomer(customer);

Background refinement threads inspect dirty cards and record the references that cross region boundaries. Previously, application threads and refinement threads worked with the same card table. They needed additional synchronization to avoid interfering with one another. This synchronization made each write barrier more expensive. The cost became noticeable in applications that frequently create objects or update fields, such as caches, in-memory data stores, and request-processing systems.

JEP 522 introduces a second card table. Application threads write to the active table, while refinement threads process the other table. G1 swaps the tables when the active table needs refinement.

The two groups of threads can now perform most of their work independently. This reduces synchronization and makes object-reference updates cheaper. Published benchmarks showed throughput improvements of 5–15% in reference-heavy workloads. Workloads with fewer reference updates gained up to approximately 5%.

The second table requires additional native memory equal to roughly 0.2% of the heap. This is about 2 MB for every 1 GB of heap space. Applications already using G1 receive the improvement without code or configuration changes. However, the result depends on how frequently an application updates references. We should therefore verify the gain with a representative workload.

3.2. AOT Object Caching with Any GC

A Java application performs several operations before it can handle useful work. The JVM loads and links classes, verifies bytecode, and creates frequently used objects. Framework-based applications may repeat a large amount of this work on every start.

The ahead-of-time cache moves some of that work to an earlier training run. During training, the JVM records classes and heap objects used by the application. Later executions can load those prepared artifacts instead of creating everything again.

For example, the cache may contain Class objects together with their related strings and byte arrays. Reusing these objects can reduce both startup time and the time required to reach peak performance.

The difficulty is that garbage collectors don’t always represent object references in the same way. A cached object prepared for one collector may contain references that another collector can’t use directly. This previously limited AOT object caching to compatible garbage collectors.

JEP 516 adds a collector-independent representation for cached objects. Instead of storing references in a format tied to one collector, the cache can store objects in a form that the JVM converts while loading them. JDK 26 can therefore use two approaches. A GC-specific cache can be mapped directly into memory for a fast warm start. A GC-independent cache can be streamed into the heap and converted to the selected collector’s object format.

AOT object caching now works with every garbage collector, including ZGC. This allows applications to combine faster startup and warmup with ZGC’s low-pause behavior.

3.3. Smaller Default Initial Heap

The JVM also prepares an initial amount of heap memory at startup. We can set this value explicitly with -Xms or -XX:InitialHeapSize. When neither option is present, the JVM calculates a default.

Earlier releases based the default on 1.5625% of the machine’s physical memory. This is approximately one sixty-fourth of the available RAM.

Consequently, a high-memory server could receive a surprisingly large initial heap. On a machine with 256 GB of memory, 1.5625% represents roughly 4 GB before other JVM sizing rules are considered. A small service may not need anything close to that amount during startup. Preparing a larger heap involves additional initialization and metadata work. This can delay startup even though most of the initial space remains unused.

JDK 26 now uses MinHeapSize  as the default initial heap when no explicit size is configured. The JVM starts with a smaller heap and expands it as the application requires more memory.

This change reduces unnecessary startup work for applications that rely on the default heap settings. Applications that already provide –Xms or –XX:InitialHeapSize retain their configured behavior.

4. Compiler and Runtime Improvements

The C2 compiler can now optimize methods with very large parameter lists. Such methods previously remained on C1-compiled or interpreted paths. This change mainly helps generated code and frameworks that create unusually wide method signatures.

C2 also has a better cost model for SuperWord loop vectorization. Processing several values with SIMD instructions can be faster than scalar execution. However, packing, shuffling, and combining vectors also cost CPU time. The improved model helps C2 vectorize a loop only when the expected gain outweighs that extra work. No application changes are required.

Finally, virtual threads can unmount from their carrier threads while waiting for class initialization in common paths. Before JDK 26, this wait could pin a carrier and prevent it from running other virtual threads. The change improves scalability during bursts of class loading and reduces the risk of carrier starvation.

5. Measuring the Upgrade

Performance changes depend on allocation patterns, reference updates, startup behaviour, hardware, and the selected garbage collector. Therefore, an upgrade test should compare the same workload, JVM options, heap limits, and traffic profile on both JDK versions.

We can record Java Flight Recorder data during a representative run:

java -XX:StartFlightRecording=filename=jdk26.jfr,settings=profile \
	-jar application.jar

Useful comparisons include startup time, request throughput, allocation rate, GC pause distribution, and CPU consumption. For an AOT cache, the training workload should also cover the application’s normal startup path.

The best result is a repeatable improvement in the application’s own service-level metrics. A synthetic benchmark is useful for isolating a feature, but it doesn’t replace an end-to-end measurement.

6. Conclusion

In this article, we explored the main performance improvements in JDK 26. We looked at lazy constants, lower-allocation library code, G1’s reduced synchronization, broader AOT caching, smarter C2 decisions, and better virtual-thread behavior.

Most of these optimizations require little or no source change. By testing JDK 26 with production-like workloads, we can determine which improvements translate into meaningful gains for our applications.