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:
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 monitorenter and monitorexit operations, letting Orca optimize locking on unescaped objects.
- -XX:+UseTaggedAddressForJavaHeap is enabled by default on ARM64. When -Xmx exceeds 512 GB, Zing disables the option and logs a warning.
- The experimental -XX:+UseZlibNG option 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:+UseThreadOpt and -XX:ThreadOptOptions) is deprecated and prints a warning when used.
- Runtime bundle size is down, from shipping stripped librpc.so and librpccpp.so.
- Stability fixes worth naming: a crash in non-ZST mode when -XX:+UseLargePages was used with a huge page size other than 2 MB, a crash in AsyncGetCallTrace when ucontext was 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:ProfileLogOutMaxNominatedGenerationCount changed 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:+EnableRNO can no longer be used with -XX:ProfileLogName. Zing fails to start with an error pointing you to -XX:ProfileName instead. 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.
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 a RECOMPSCANSTATS line.
- A new option, -XX:FalconIntrinsifyFillInStackTrace0, controls use of the Throwable.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:+UseThreadOpt and -XX:ThreadOptOptions
No longer valid together:
- -XX:+EnableRNO with -XX:ProfileLogName. Use -XX:ProfileName.
OpenJDK versions in 26.08.1.0
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.
