Код сначала интерпретируется, горячие методы компилирует C1 (быстро, с профилированием), затем C2 (агрессивные оптимизации по профилю). Оптимизации спекулятивны: встраивание по наблюдавшемуся типу, удаление невыполнявшихся веток. Предположение нарушилось — деоптимизация и возврат в интерпретатор.
А ещё JIT знает реальный профиль — преимущество перед статической компиляцией
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
JIT опирается на профиль реального выполнения, и в этом его преимущество перед статической компиляцией: он видит, какая ветка берётся чаще и какой конкретный тип приходит в вызов. На этом строятся спекулятивные оптимизации — встраивание виртуального вызова по фактически наблюдавшемуся типу, устранение проверок, удаление недостижимых ветвей. Поскольку предположение может нарушиться (загрузился новый класс, ветка наконец сработала), в код вставляются проверки, а при их срабатывании происходит деоптимизация и возврат к интерпретации. Практический вывод — измерять производительность можно только после прогрева, и именно поэтому самодельные бенчмарки на System.nanoTime обычно врут, а пользоваться следует JMH.
Несколько верных вариантов. Подумайте, потом откройте ответ.
Tiered compilation C1/C2, ключевые оптимизации JIT (inlining, escape analysis), деоптимизация и прогрев, корректные микробенчмарки на JMH.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto