При загрузке нового подкласса ранее скомпилированный вызов метода начинает выполняться медленнее. Как JVM сохраняет корректность такой оптимизации?
JVM может отменить оптимизацию через деоптимизацию, если загрузка нового подкласса нарушила предположение JIT-компилятора о структуре иерархии классов. Скомпилированный код помечается как больше не подходящий для дальнейшего использования, а выполнение переводится в интерпретируемый код или более общий машинный код.
Это не означает, что любая загрузка класса автоматически вызывает деоптимизацию: она происходит только тогда, когда новый класс способен изменить результат предположения, использованного конкретной оптимизацией.
Java поддерживает динамическую загрузку классов, поэтому полная информация об иерархии типов может измениться уже после начала работы приложения. Одновременно JIT-компилятору нужна возможность использовать наблюдаемые свойства программы, чтобы генерировать более быстрый специализированный код.
Так возникает компромисс: JVM временно доверяет проверяемому предположению, но должна уметь безопасно отказаться от него при изменении условий. Деоптимизация решает эту задачу без требования заранее компилировать каждый вызов максимально консервативно.
Предположим, JIT видит, что у виртуального вызова фактически существует один подходящий класс. Он может встроить вызываемый метод или заменить виртуальный вызов прямым переходом, не проверяя полный набор возможных реализаций при каждом обращении.
Если затем загружается новый подкласс с переопределённым методом, прежний машинный код может стать логически неверным. Простое продолжение его выполнения привело бы к вызову неправильной реализации, поэтому JVM должна обнаружить нарушение предположения и безопасно вывести такой код из использования.
JIT-компилятор строит оптимизации на зависимостях, среди которых может быть анализ иерархии классов. Например, он предполагает, что у класса пока нет подклассов с переопределённым методом, и поэтому выполняет встраивание или превращает виртуальный вызов в более дешёвый специализированный переход.
При загрузке нового класса JVM проверяет зависимости скомпилированного кода. Если новая информация делает оптимизацию небезопасной, соответствующий машинный код помечается как недействующий для новых входов. Уже выполняющийся код не обрывается произвольным образом: переход к безопасному состоянию обычно происходит на контролируемой точке, после чего JVM выполняет деоптимизацию.
Во время деоптимизации JVM восстанавливает логическое состояние метода: локальные переменные, стек вызовов и текущую позицию выполнения. Для этого JIT сохраняет метаданные, позволяющие сопоставить оптимизированное состояние с состоянием, которое ожидал бы интерпретатор.
После перехода выполнение может продолжиться в интерпретаторе. Позднее метод иногда компилируется заново — уже с учётом новой иерархии и фактического профиля вызовов. Новый код может быть менее специализированным, использовать защитные проверки или поддерживать несколько вариантов реализации.
Практическое следствие — кратковременное падение производительности и возможные задержки на повторную компиляцию. Деоптимизация не равна утечке памяти и не означает ошибку приложения; это штатный механизм поддержания корректности спекулятивных оптимизаций.
В сервере редко используется расширяемая архитектура: основной код долго работает с единственной реализацией интерфейса, а затем загружается плагин с новой реализацией. JIT успевает встроить вызов и оптимизировать горячий путь, но после загрузки плагина часть ранее скомпилированного кода становится неприменимой.
Можно запретить JIT оптимизировать такие вызовы, но это снижает производительность всего горячего пути. Можно также заранее загрузить все плагины, однако это увеличивает время запуска и расход памяти.
Обычно выбирают сохранение стандартного поведения JVM: разрешают спекулятивные оптимизации, а загрузку плагинов выполняют до прогрева критичных путей. Если динамическая загрузка обязательна, её влияние проверяют по JFR, журналам компиляции и профилю задержек. Такой подход сохраняет оптимизацию в стабильном режиме и делает неизбежную перестройку кода контролируемой.
Нет. Загрузка класса сама по себе не требует отмены всех оптимизаций. JVM анализирует зависимости: деоптимизация нужна только для тех скомпилированных участков, чьи предположения действительно могли быть нарушены. Новый класс без переопределения relevant-метода может не повлиять на конкретный оптимизированный вызов.
Потому что активный метод мог уже находиться внутри встроенного или специализированного участка, где старое предположение влияет на текущий путь выполнения. JVM переводит выполнение через безопасную точку и восстанавливает корректное логическое состояние, после чего продолжает его в менее оптимизированном представлении. Это предотвращает выполнение неверной реализации даже внутри уже начатого вызова.
Нет. Метод может быть повторно скомпилирован с новым профилем и актуальными предположениями. Однако новый код часто оказывается менее специализированным: вместо одного типа ему приходится учитывать несколько типов, выполнять проверки или отказаться от встраивания. Если классы продолжают динамически загружаться, последующие деоптимизации и перекомпиляции могут повторяться.