AOT-кеш обещает ускорить запуск Java-приложений без перехода на GraalVM Native Image. Во время тренировочного запуска JVM записывает загруженные классы и профили методов, а при следующем старте пропускает часть подготовительной работы. На практике XPipe обнаружил, что результат сильно зависит от машины и настроек.
Самая неприятная проблема — процессоры. Кеш со связанными классами содержит небольшие фрагменты машинного кода, адаптированные под CPU тренировочной системы. Если у пользователя нет нужных инструкций AVX, JVM падает с SIGILL вместо запуска. Это опасно и для десктопных приложений, и для контейнеров, собранных в CI на одном железе, а развёрнутых на другом.
До исправления разработчику пришлось отключать AOTAdapterCaching недокументированным флагом. В JDK 27 кеш адаптеров будет применяться только при точном совпадении CPU-функций. В JDK 28 появится полноценная AOT-компиляция кода, но такая строгая проверка сделает её малополезной для приложений, распространяемых среди разных пользователей.
Вторая группа проблем — тихая потеря оптимизаций. Кеш может загрузиться успешно, но без AOT class linking, то есть без важной части выигрыша. На это влияют параметры модулей, incubating-модули JavaFX, особенности GraalVM и даже настройки предупреждений об illegal access. Понятного способа заставить CI падать при отключении связывания нет.
Логи тоже не упрощают жизнь: один запуск на самом деле содержит два прохода JVM, похожие сообщения означают разное, а документацию приходится искать одновременно в JEP, CDS и исходниках HotSpot.
Отдельные сложности создают относительные пути к кешу и EDR-агенты. Последние мешают загрузке классов из кеша, а ошибки JVM неожиданно попадают в stdout и ломают скрипты, ожидающие чистый вывод команды.
Вывод автора: технология полезна, но пока требует чтения исходников JDK и осторожной сборки. Для зрелой функции ей не хватает предсказуемости, документации и безопасного режима совместимости.