Если вы используете стабильную сборку 26.02, переход на 26.08 объединяет шесть месяцев работы над потоковыми сборками (Stream Build) в одно обновление, причем за один из этих месяцев появилась возможность полностью пропустить большую часть прогрева JIT.
К концу этого поста вы будете точно знать, что изменилось между 26.02.0.0 и 26.08.1.0: какие значения по умолчанию теперь отличаются (особенно на ARM64), какие параметры вышли из статуса экспериментальных, какая комбинация параметров остановит запуск вашей JVM и какие исправления безопасности вы получаете при обновлении.
Как связаны потоковая и стабильная линейки
Azul Zing Builds of OpenJDK, оптимизированная среда выполнения Java в составе Azul Prime, выпускается в двух вариантах.
Потоковые сборки (Stream Builds) выпускаются ежемесячно и содержат новейшие функции, а также изменения из наборов исправления патчей (PSU). Номер версии состоит из года и месяца, поэтому 26.08.0.0 — это августовская потоковая сборка 2026 года. Вы можете получить потоковые сборки, запросив пробную версию Azul Prime.
Стабильные сборки (Stable Builds) создаются на основе потоковых сборок и обновляются только критическими обновлениями патчей (CPU), PSU и критическими исправлениями Zing — без добавления новых функций и некритических изменений. Именно так Azul доставляет клиентам срочные исправления, и они доступны только клиентам. Номер сохраняет преемственность происхождения: 26.08.1.0 создана на базе августовской потоковой сборки 2026 года, а цифра 1 обозначает ее как первое обновление с момента выпуска.
Два раза в год, в феврале и августе, потоковая сборка получает статус новой стабильной сборки. Стабильная сборка 26.08 — это августовское продвижение 2026 года, и все описанное ниже попало в потоковые сборки между этими двумя релизами. Потоковой сборки 26.03 не было, поэтому диапазон охватывает версии с 26.04 по 26.08.
Потоковая компиляция (Compilation Streaming)
Потоковая компиляция позволяет каждой JVM при запуске скачивать поток предварительно скомпилированного кода из Azul Optimizer Hub и устанавливать его напрямую, что сокращает время очереди компиляции во время прогрева. Вместо того чтобы ждать, пока собственный компилятор обработает очередь, JVM начинает работу с уже скомпилированным кодом.
Эта функция работает через Cloud Native Compiler и должна быть включена с обеих сторон. На сервере запущен Optimizer Hub 26.08.0 или более поздней версии, а также задан параметр compilationStreaming.enabled; компонент task-executor, собирающий потоки, развертывается по умолчанию начиная с Optimizer Hub 26.08.0, поэтому отдельного включения не требуется. На стороне JVM добавьте флаг -XX:+CNCEnableCompilationStreaming.
Параметры, управляющие этой функцией:
Одно примечание, если вы следили за этой функцией в потоковой линейке: сбой JVM, который мог произойти при разрешении компиляции из потока, был зафиксирован как известная проблема в версии 26.08.0.0. Он исправлен в версии 26.08.1.0, поэтому в стабильной линейке потоковая компиляция доступна без этого оговорки.
Исправления безопасности
Стабильная линейка 26.08 включает исправления безопасности из релизов CPU и PSU за апрель и июль 2026 года, а также августовское критическое обновление безопасности (CSPU) 2026 года.
CSPU — это новый формат 2026 года. Он доставляет исправления безопасности и стабильности в промежутках между квартальными обновлениями и не добавляет новых функций, изменений API и поведения, за исключением самих исправлений безопасности. Августовское CSPU 2026 года стало первым релизом такого рода для Azul Zing Builds of OpenJDK.
Общие улучшения
- Схема легковесного блокирования теперь имеет потоко-локальные варианты операций monitorenter и monitorexit, что позволяет Orca оптимизировать блокировки для неизвлекаемых (unescaped) объектов.
- Параметр -XX:+UseTaggedAddressForJavaHeap теперь включен по умолчанию на ARM64. Когда значение -Xmx превышает 512 ГБ, Zing отключает этот параметр и записывает предупреждение в лог.
- Экспериментальный параметр -XX:+UseZlibNG теперь можно включать на JDK 25. zlib-ng — это оптимизированная по производительности замена zlib, которая в некоторых случаях может повысить пропускную способность и снизить нагрузку на CPU; в версиях для JDK 11, 17 и 21 она появилась в 26.02.0.0, а поддержка JDK 25 закрывает этот пробел.
- MXBean памяти Metaspace добавлен для совместимости с OpenJDK. Поскольку Zing отслеживает метаданные в куче Java, что уже покрывается существующим MXBean кучи Zing, этот компонент всегда сообщает о нулевом использовании. Он отключен по умолчанию и включается с помощью -XX:+EnableMetaspacePoolMXBean.
- Функция ThreadOpt (-XX:+UseThreadOpt и -XX:ThreadOptOptions) устасела и при использовании выводит предупреждение.
- Размер дистрибутива среды выполнения уменьшился за счет отказа от включения урезанных библиотек librpc.so и librpccpp.so.
- Стоит отметить следующие исправления стабильности: сбой в режиме без ZST, когда -XX:+UseLargePages использовался с размером огромных страниц (huge pages), отличным от 2 МБ; сбой в AsyncGetCallTrace, когда ucontext был равен null (что затрагивало некоторые режимы async-profiler); запись блоков JFR, выполняемая при удерживании блокировки JVM, которая могла вызывать многосекундные задержки time-to-safepoint; а также инициализацию JFR множества рекомпиляций при подключении (attach), когда ZVision этого не делал.
Optimizer Hub, локальный резервный режим и ReadyNow
- Методы, скомпилированные с пониженным уровнем оптимизации во время локального резервного режима (local fallback), теперь перекомпилируются на целевом уровне, как только Cloud Native Compiler снова становится доступен.
- Новый параметр -XX:CNCProductivityRemoteCpuToLocalCpuEquivalenceFactor настраивает принятие решений о локальном резервном режиме на основе производительности.
- Значение по умолчанию для -XX:ProfileLogOutMaxNominatedGenerationCount изменено с 0 (бесконечно) на 4, что делает третье поколение профиля ReadyNow максимальным уровнем, номинируемым виртуальной машиной при использовании Cloud Native Compiler.
- Параметр -XX:+EnableRNO больше нельзя использовать совместно с -XX:ProfileLogName. Zing завершает работу с ошибкой, указывающей на необходимость использовать -XX:ProfileName. Эта ошибка проявится при запуске, а не тихо, поэтому проверьте свои флаги перед обновлением.
Многоуровневая компиляция (Multi-tiering)
Три командные строки многоуровневой компиляции теперь являются продуктовыми параметрами, поэтому их установка больше не требует флага -XX:+UnlockExperimentalVMOptions.
Сама многоуровневая компиляция по-прежнему отключена по умолчанию. Включите ее с помощью параметра -XX:+UseMultiTiering.
Логирование сборщика мусора и компилятор Falcon
- Новый параметр -XX:GCLogPrintRecompStatistics записывает статистику рекомпиляции в лог сборщика мусора в строке RECOMPSCANSTATS.
- Новый параметр -XX:FalconIntrinsifyFillInStackTrace0 управляет использованием интринсика Throwable.fillInStackTrace0(int).
- Запись в лог сборщика мусора, выполняемая при удерживании блокировки JVM, могла вызывать тайм-ауты контрольных точек (checkpoint). Исправлено.
Краткий обзор изменений параметров командной строки
Новые:
- -XX:[+/-]CNCEnableCompilationStreaming, -XX:CNCCompilationStreamingMaxActiveSegments, -XX:CNCCompilationStreamingStopAfterSeconds и -XX:[+/-]CNCCompilationStreamingPrintStatsAtExit
- -XX:CNCProductivityRemoteCpuToLocalCpuEquivalenceFactor
- -XX:GCLogPrintRecompStatistics
- -XX:FalconIntrinsifyFillInStackTrace0
- -XX:+EnableMetaspacePoolMXBean
Переведены из экспериментальных в продуктовые параметры:
- -XX:MultiTieringSamplingIntervalMS, -XX:MultiTieringSamplingStartDelayMS и -XX:FalconMidTierOptimizationLevel
Измененные значения по умолчанию:
- -XX:ProfileLogOutMaxNominatedGenerationCount, с 0 (бесконечно) на 4
- -XX:+UseTaggedAddressForJavaHeap, теперь включен по умолчанию на ARM64
Устаревшие:
- -XX:+UseThreadOpt и -XX:ThreadOptOptions
Более не совместимы друг с другом:
- -XX:+EnableRNO и -XX:ProfileLogName. Используйте -XX:ProfileName.
Версии OpenJDK в 26.08.1.0
Одно обновление дает вам шесть месяцев работы над потоковой сборкой, предварительно скомпилированный код, поступающий по потоку при запуске, и каждое исправление безопасности OpenJDK по август 2026 года включительно.
Часто задаваемые вопросы
Как сократить время прогрева JVM в продакшене?
Время подготовки к работе в основном определяется JIT-компиляцией, поэтому самый быстрый способ сократить его — избежать компиляции с нуля при каждом запуске. Azul Prime решает эту задачу с помощью ReadyNow, которая повторно использует информацию профилирования от предыдущих запускaв, и Compilation Streaming, позволяющей JVM загружать предварительно скомпилированный код из Azul Optimizer Hub при запуске и устанавливать его напрямую, вместо ожидания собственной очереди компиляции. Функция Compilation Streaming была представлена в релизе Azul Prime 26.08 и требует наличия Azul Optimizer Hub 26.08.0 или более поздней версии.
В чем разница между потоковым (stream) релизом и стабильным (stable) релизом среды выполнения Java?
Потоковые релизы выпускаются часто и содержат новые функции наряду с плановыми обновлениями, в то время как стабильные релизы оставляют функциональность неизменной и включают только исправления безопасности и критические исправления. Azul Prime использует эту модель для Azul Zing Builds of OpenJDK: потоковые сборки (Stream Builds) выпускаются ежемесячно и доступны для разработки и оценки, а стабильные сборки (Stable Builds) получают только критические обновления безопасности (Critical Patch Updates), обновления наборов патчей (Patch Set Updates) и критические исправления и доступны клиентам Azul. Потоковая сборка переводится в статус новой стабильной сборки два раза в год — в феврале и августе.
Что такое критическое обновление безопасности для Java?
Критическое обновление безопасности (Critical Security Patch Update, или CSPU) содержит исправления безопасности и стабильности в промежутках между регулярными квартальными обновлениями Java. Оно не добавляет новых функций, изменений API и изменений поведения, за исключением самих исправлений безопасности, что делает его применение менее рискованным. Компания Azul выпустила первое обновление CSPU для Azul Zing Builds of OpenJDK в августе 2026 года, и оно включено в стабильную ветку Azul Prime 26.08 наряду с исправлениями Critical Patch Update и Patch Set Update за апрель и июль 2026 года.
Какие версии Java можно запускать на оптимизированной для производительности JVM?
Azul Prime 26.08 поддерживает OpenJDK 8, 11, 17, 21 и 25, что соответствует 1.8.0_504-b2, 11.0.32.1+1-LTS, 17.0.20.1+1-LTS, 21.0.12.1+1-LTS и 25.0.4.1+1-LTS. Java 25 является релизом с долгосрочной поддержкой (Long-Term Support), и поддержка для него появилась в релизе Azul Prime 26.02. Использование более старой мажорной версии не лишает вас текущих оптимизаций, поскольку каждый релиз распространяется на все поддерживаемые версии.
Что дают несколько уровней JIT-компилятора для производительности Java-приложений?
Несколько уровней компилятора позволяют JVM быстро компилировать код на низком уровне оптимизации на раннем этапе, а затем перекомпилировать важный код на более высоком уровне, что жертвует небольшой частью пиковой производительности ради гораздо более быстрого прогрева. Azul Prime реализует это в виде функции Multi-Tiering, которая отключена по умолчанию и включается с помощью параметра командной строки -XX:+UseMultiTiering. Начиная с релиза Azul Prime 26.08, интервал сэмплирования, задержка запуска сэмплирования и уровень оптимизации среднего уровня стали продуктовыми параметрами, которые больше не требуют разблокировки экспериментальных опций виртуальной машины.
