Насколько мне известно, JVM может работать по-разному:
Интерпретатор: время выполнения переводит из байт-кода в собственный код снова и снова.
Своевременная компиляция: при необходимости компилируйте части байт-кода в машинный код во время выполнения. Хранение сборников. Накладные расходы / штраф за компиляцию. Предоставляет возможности для адаптивной оптимизации во время выполнения, что невозможно при статической предварительной компиляции.
Hotspot: только часто выполняемые части компилируются JIT. Остальное интерпретируется.
Теперь GraalVM может выполнять предварительную компиляцию байт-кода в собственный код.
Можно ли заранее скомпилировать байт-код и провести адаптивную оптимизацию в горячих точках (в целом и с GraalVM в частности)?
[Уточнение] Я не имею в виду, чтобы AOT компилировал части байт-кода в машинный код и оставлял другие части как байт-код для выполнения JIT-компиляции горячей точки во время выполнения. Это то, что, по-видимому, делает Java-реализация IBM Excelsior Jet, о чем я до сих пор читал. Я имею в виду, что AOT компилирует весь байт-код и заменяет части горячих точек во время выполнения адаптивно оптимизированными перекомпиляциями горячих точек. Это требует правильного подключения / вставки оптимизированного кода в существующий скомпилированный код AOT. [/ разъяснение]
Я не знаю, какая информация нужна для перекомпиляции горячих точек с адаптивной оптимизацией во время выполнения. Нужен ли для этого байт-код? Это означало бы более высокое потребление памяти как стоимость более высокой производительности.
Я не являюсь экспертом в этом вопросе, поэтому, пожалуйста, скажите мне, если какое-либо предположение неверно.
