Почему сложно компилировать компилятор AOT с помощью JIT-компилятора (с точки зрения производительности приложения)?

Я думал, что компиляторы JIT в конечном итоге будут бить AOT-компиляторы с точки зрения производительности скомпилированного кода из-за присущего JIT (можно использовать информацию, доступную только во время выполнения). Один из аргументов заключается в том, что компиляторы AOT могут тратить больше времени на компиляцию кода, но серверная VM тоже может потратить много времени.

Я понимаю, что JIT, похоже, в некоторых случаях превзошел компиляторы AOT, но в большинстве случаев они по-прежнему отстают.

Итак, мой вопрос: каковы конкретные, жесткие проблемы, которые мешают компиляторам JIT бить компиляторы AOT?

EDIT:
Некоторые общие аргументы:

Компиляторы AOT могут потратить больше времени на выполнение расширенных оптимизаций → Если вы используете VM на сервере в течение нескольких дней, вы можете потратить такое же количество времени, если не дольше.
Интерпретация байт-кода имеет стоимость → . Большинство компиляторов JIT кэшируют собственные машинные инструкции в наши дни.

Еще одно редактирование:
Для конкретного примера см. Эту статью: Улучшение производительности Swing: JIT vs AOT Compilation. Из того, что я могу извлечь из этой статьи, авторы в основном говорят, что, когда нет горячих точек, преимущество в том, что информация о времени выполнения уменьшается и, таким образом, AOT без накладных расходов JIT, выигрывает. Но на 40%? Это, похоже, не имеет большого смысла. Это просто, что компилятор JIT, который был сравнен, не был настроен для этой ситуации? Или это нечто более фундаментальное?

Ответ 1

Здесь существует определенная компромиссная между компиляцией JIT и AOT (впереди).

Как вы сказали, JIT имеет доступ к информации о времени выполнения, которая может помочь в оптимизации. Сюда входят данные о машине, на которой он выполняется, что позволяет использовать собственную оптимизацию на основе платформы. Однако JIT также имеет накладные расходы на перевод байт-кода на собственные инструкции.

Эти накладные расходы часто становятся очевидными в приложениях, где требуется быстрый запуск или ответы в режиме реального времени. JIT также не так эффективен, если машина не имеет достаточных ресурсов для расширенной оптимизации или если характер кода таков, что он не может быть "агрессивно оптимизирован".

Например, взято из связанная статья:

... что мы должны улучшить отсутствие узких мест в производительности? Как вы можете догадались, такая же проблема существует для JIT с профилем компиляторы. Вместо того, чтобы агрессивно оптимизировать несколько горячих точек, есть много "теплых пятен", которые остались нетронутыми.

Компиляторы AOT также могут тратить столько времени, сколько им нравится, тогда как компиляция JIT связана требованиями времени (для поддержания отзывчивости) и ресурсами клиентской машины. По этой причине компиляторы AOT могут выполнять сложную оптимизацию, которая была бы слишком дорогостоящей во время JIT.

Также см. этот вопрос SO: JIT-компилятор против автономных компиляторов