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