If you are running the 26.02 Stable Build, moving to 26.08 collapses six months of Stream Build work into a single upgrade — and one of those months added a way to skip a large part of your JIT warmup altogether.
By the end of this post you will know exactly what changed between 26.02.0.0 and 26.08.1.0: which defaults now differ, particularly on ARM64, which options graduated out of experimental status, which option combination will stop your JVM from starting, and which security fixes you inherit by upgrading.
How the Stream and Stable lines relate
Azul Zing Builds of OpenJDK, the optimized Java runtime in Azul Prime, ships in two lines.
Stream Builds are released monthly with the newest features and Patch Set Update (PSU) changes. The version number is the year and month, so 26.08.0.0 is the August 2026 Stream Build. You can get Stream Builds by requesting an Azul Prime trial.
Stable Builds are derived from a Stream Build and updated only with Critical Patch Updates (CPUs), PSUs, and critical Zing fixes — no new features and no non-critical changes. They are how Azul delivers time-sensitive fixes to customers, and they are available to customers only. The number carries the origin forward: 26.08.1.0 came from the August 2026 Stream Build, and the 1 marks it as the first update since.
Twice a year, in February and August, a Stream Build is promoted to become the new Stable Build. The 26.08 Stable Build is that August 2026 promotion, and everything below arrived in the Stream Builds between the two promotions. There was no 26.03 Stream Build, so the range is 26.04 through 26.08.
Compilation Streaming
Compilation Streaming lets each JVM download a stream of pre-compiled code from Azul Optimizer Hub at startup and install it directly, which cuts compilation queue time during warmup. Rather than waiting for its own compiler to work through the queue, the JVM starts with code that is already compiled.
The feature works through Cloud Native Compiler and has to be enabled on both sides. On the server, run Optimizer Hub 26.08.0 or later and set compilationStreaming.enabled; the task-executor component that builds the streams is deployed by default as of Optimizer Hub 26.08.0, so it needs no opt-in of its own. On the JVM, add -XX:+CNCEnableCompilationStreaming.
The options that control it:
| Command-Line Option | Description | Default |
|---|---|---|
-XX:[+/-]CNCEnableCompilationStreaming |
Enables compilation streaming. The JVM connects to Optimizer Hub and downloads a compiled-code stream at startup. Cannot be used together with Indirect Delivery of the ReadyNow Orchestrator profile, where the JVM downloads the profile over HTTP from a pre-signed URI instead of over gRPC from Optimizer Hub. | false |
-XX:CNCCompilationStreamingMaxActiveSegments=<number> |
The number of stream segments held in memory at the same time. Each segment contains 500 compilations by default. A value of 3 to 5 suits most production workloads. | 6 |
-XX:CNCCompilationStreamingStopAfterSeconds=<value in seconds> |
Stops compilation streaming and frees its memory this many seconds after the VM starts. -1 never stops streaming, and 0 stops it immediately. |
600 |
-XX:[+/-]CNCCompilationStreamingPrintStatsAtExit |
Prints a summary of stream installation successes and failures when the JVM exits. Useful during initial validation and performance testing. | false |
One note if you tracked this feature through the Stream line: a JVM crash that could occur while resolving a compilation from a stream was reported as a known issue in 26.08.0.0. It is resolved in 26.08.1.0, so the Stable Line carries Compilation Streaming without that caveat.
Security fixes
The 26.08 Stable Line includes the security fixes from the April 2026 and July 2026 CPU and PSU releases, plus the August 2026 Critical Security Patch Update (CSPU).
The CSPU is new in 2026. It delivers security and stability fixes in between the quarterly update releases and introduces no new features, no API changes, and no behavior changes beyond the security fixes themselves. The August 2026 CSPU was the first one issued for Azul Zing Builds of OpenJDK.
General improvements
- The lightweight locking scheme now has thread-local variants of the
monitorenterandmonitorexitoperations, letting Orca optimize locking on unescaped objects. -XX:+UseTaggedAddressForJavaHeapis enabled by default on ARM64. When-Xmxexceeds 512 GB, Zing disables the option and logs a warning.- The experimental
-XX:+UseZlibNGoption can now be enabled on JDK 25. zlib-ng is a performance-optimized drop-in replacement for zlib that can raise throughput and lower CPU usage in some cases; it arrived in 26.02.0.0 for JDK 11, 17, and 21, and JDK 25 support closes the gap. - The Metaspace MemoryPool MXBean is included for OpenJDK compatibility. Because Zing tracks metadata in the Java heap, already covered by the existing Zing Heap MXBean, this one always reports 0 usage. It is off by default and enabled with
-XX:+EnableMetaspacePoolMXBean. - ThreadOpt (
-XX:+UseThreadOptand-XX:ThreadOptOptions) is deprecated and prints a warning when used. - Runtime bundle size is down, from shipping stripped
librpc.soandlibrpccpp.so. - Stability fixes worth naming: a crash in non-ZST mode when
-XX:+UseLargePageswas used with a huge page size other than 2 MB, a crash inAsyncGetCallTracewhenucontextwas null (which affected some async-profiler modes), JFR chunk file writes made while holding the JVM lock that could cause multi-second time-to-safepoint stalls, and JFR triggering many recompilations on attach when ZVision did not.
Optimizer Hub, local fallback, and ReadyNow
- Methods compiled at a reduced optimization level during local fallback are now recompiled at their intended level once Cloud Native Compiler becomes reachable again.
- A new option,
-XX:CNCProductivityRemoteCpuToLocalCpuEquivalenceFactor, tunes the productivity-based local fallback decision. - The default for
-XX:ProfileLogOutMaxNominatedGenerationCountchanged from 0 (infinite) to 4, making the third generation of a ReadyNow profile the maximum level the VM nominates when using Cloud Native Compiler. -XX:+EnableRNOcan no longer be used with-XX:ProfileLogName. Zing fails to start with an error pointing you to-XX:ProfileNameinstead. This one will surface at startup rather than quietly, so check your flags before you upgrade.
Multi-tiering
Three Multi-Tiering command-line options are now product options, so setting them no longer requires -XX:+UnlockExperimentalVMOptions.
| Command-Line Option | Description | Default |
|---|---|---|
-XX:MultiTieringSamplingIntervalMS=<value in milliseconds> |
The interval at which Multi-Tiering samples methods. Tune this to control the CPU cost of sampling. | 60000 |
-XX:MultiTieringSamplingStartDelayMS=<value in milliseconds> |
The delay before Multi-Tiering starts sampling. Increase this to skip the early startup window. | 0 |
-XX:FalconMidTierOptimizationLevel=<level> |
The Falcon optimization level used for mid-tier compilation, trading mid-tier compile cost against code quality. | 0 |
Multi-Tiering itself is still disabled by default. Enable it with -XX:+UseMultiTiering.
Garbage collection logging and the Falcon compiler
- A new option,
-XX:GCLogPrintRecompStatistics, logs recompilation statistics to the GC log on aRECOMPSCANSTATSline. - A new option,
-XX:FalconIntrinsifyFillInStackTrace0, controls use of theThrowable.fillInStackTrace0(int)intrinsic. - GC log writes made while holding the JVM lock could cause checkpoint timeouts. Fixed.
Command-line option changes at a glance
New:
-XX:[+/-]CNCEnableCompilationStreaming,-XX:CNCCompilationStreamingMaxActiveSegments,-XX:CNCCompilationStreamingStopAfterSeconds, and-XX:[+/-]CNCCompilationStreamingPrintStatsAtExit-XX:CNCProductivityRemoteCpuToLocalCpuEquivalenceFactor-XX:GCLogPrintRecompStatistics-XX:FalconIntrinsifyFillInStackTrace0-XX:+EnableMetaspacePoolMXBean
Promoted from experimental to product options:
-XX:MultiTieringSamplingIntervalMS,-XX:MultiTieringSamplingStartDelayMS, and-XX:FalconMidTierOptimizationLevel
Changed defaults:
-XX:ProfileLogOutMaxNominatedGenerationCount, from 0 (infinite) to 4-XX:+UseTaggedAddressForJavaHeap, now enabled by default on ARM64
Deprecated:
-XX:+UseThreadOptand-XX:ThreadOptOptions
No longer valid together:
-XX:+EnableRNOwith-XX:ProfileLogName. Use-XX:ProfileName.
OpenJDK versions in 26.08.1.0
| Major Version | OpenJDK Version |
|---|---|
| 8 | 1.8.0_504-b2 |
| 11 | 11.0.32.1+1-LTS |
| 17 | 17.0.20.1+1-LTS |
| 21 | 21.0.12.1+1-LTS |
| 25 | 25.0.4.1+1-LTS |
One upgrade gets you six months of Stream Build work, pre-compiled code streamed in at startup, and every OpenJDK security fix through August 2026.
Frequently Asked Questions
How can I reduce JVM warm-up time in production?
Warm-up time is dominated by JIT compilation, so the fastest way to reduce it is to avoid compiling from scratch at every start. Azul Prime addresses this with ReadyNow, which reuses profiling information from previous runs, and with Compilation Streaming, which lets the JVM download pre-compiled code from Azul Optimizer Hub at startup and install it directly instead of waiting on its own compilation queue. Compilation Streaming was introduced in the Azul Prime 26.08 release and requires Azul Optimizer Hub 26.08.0 or later.
What is the difference between a stream release and a stable release of a Java runtime?
Stream releases ship frequently and carry new features alongside routine updates, while stable releases hold features constant and take only security and critical fixes. Azul Prime uses this model for Azul Zing Builds of OpenJDK: Stream Builds are released monthly and are available for development and evaluation, and Stable Builds take only Critical Patch Updates, Patch Set Updates, and critical fixes and are available to Azul customers. A Stream Build is promoted to become the new Stable Build twice a year, in February and August.
What is a Critical Security Patch Update for Java?
A Critical Security Patch Update, or CSPU, delivers security and stability fixes in between the regular quarterly Java update releases. It introduces no new features, no API changes, and no behavior changes beyond the security fixes themselves, which makes it low-risk to apply. Azul issued the first CSPU for Azul Zing Builds of OpenJDK in August 2026, and it is included in the Azul Prime 26.08 Stable Line alongside the April and July 2026 Critical Patch Update and Patch Set Update fixes.
Which Java versions can I run on a performance-optimized JVM?
Azul Prime 26.08 supports OpenJDK 8, 11, 17, 21, and 25, corresponding to 1.8.0_504-b2, 11.0.32.1+1-LTS, 17.0.20.1+1-LTS, 21.0.12.1+1-LTS, and 25.0.4.1+1-LTS. Java 25 is a Long-Term Support release, and support for it arrived in the Azul Prime 26.02 release. Running an older major version does not exclude you from current optimizations, since each release applies to all supported versions.
What do multiple JIT compiler tiers do for Java application performance?
Multiple compiler tiers let a JVM compile code quickly at a low optimization level early on and then recompile the code that matters at a higher level, which trades a small amount of peak performance for a much shorter warmup. Azul Prime implements this as Multi-Tiering, which is disabled by default and enabled with the -XX:+UseMultiTiering command-line option. As of the Azul Prime 26.08 release, its sampling interval, sampling start delay, and mid-tier optimization level are product options that no longer require unlocking experimental VM options.
