Кратко и по делу.
1) Какие оптимизации выполняют JIT (V8, JVM)
- Встраивание вызовов (inlining) — замена вызова тела функции/метода прямо в вызывающем коде для устранения вызовных расходов и раскрытия дальнейших оптимизаций.
- Спекулятивная оптимизация / type feedback — генерация кода под предполагаемые типы/формы объектов; при нарушении — деоптимизация.
- Де- и реоптимизация (deopt / bailouts) — возврат в интерпретируемый код и повторная компиляция при изменении предпосылок.
- Удаление неиспользуемого кода (dead code elimination).
- Сведение общих выражений (common subexpression elimination), свёртка констант (constant folding).
- Перенос invariant-вычислений из циклов (hoisting) и развёртывание циклов (loop unrolling).
- Устранение проверок границ массива (bounds check elimination) при доказуемой безопасности.
- Анализ побега (escape analysis) и скалярная замена (scalar replacement) — устранение аллокаций объектов, если они не «убегают» наружу.
- Дезвиртуализация / предсказуемое разрешение виртуальных вызовов (devirtualization, monomorphic/polymorphic inline cache).
- Агрегация и локализация переменных (register allocation, stack promotion).
- Векторизация / SIMD (в некоторых JIT) — преобразование циклов под SIMD-инструкции.
- Оптимизации синхронизации: biased locking, lock elision (JVM).
- Специфично для V8: скрытые классы (hidden classes) и inline caches для быстрого доступа к свойствам объектов; Sparkplug/Ignition/TurboFan pipeline (baseline → оптимизатор).
- Специфично для JVM: многоуровневая компиляция (interpreter → C1/C2 или Graal), OSR (on-stack replacement) для оптимизации долгих циклов.
2) Как они влияют на производительность
- Для "горячего" кода (многократно вызываемого) JIT может дать значительный выигрыш: от нескольких раз до десятков (в редких случаях — сотен) раз лучше интерпретируемого/байткод-исполнения — примерно $\times 2$ — $\times 100$, в зависимости от кода.
- Начальная задержка (warm‑up): до достижения «hot» состояния требуется время/вызовы (порог компиляции), поэтому стартовые/разовые сценарии выигрывают меньше.
- Спекулятивные оптимизации очень быстры, но при частых деоптимизациях производительность падает (перекомпиляции, переключения).
- Некоторые оптимизации (например, inlining) открывают дальнейшие возможности (убирают проверки, улучшают локальность данных), эффект компаундируется.
- Оптимизации уменьшают allocation/GC нагрузку (через escape analysis) и уменьшают нагрузку на кэш и ветвления (branch prediction).
3) Практики кодирования, которые помогают JIT
- Делать вызовы моноформными: один доминирующий тип на call site (monomorphic). Это ускоряет inline caches и inlining.
- Стабильная «форма» объектов: создавать объекты с одинаковым набором свойств в одном порядке (V8 hidden classes).
- Маленькие чистые функции, избегать побочных эффектов — помогают inlining и переупорядочиванию.
- Использовать примитивы вместо boxed-типов в горячих путях (JVM: int/long vs Integer).
- Позволять JIT анализировать объекты (не выносить ссылки наружу) — дружелюбные к escape analysis паттерны (локальные объекты, не сохранять в глобальные структуры).
- Предпочитать простые предсказуемые ветвления; упрощать условные выражения в hot loops.
- Для массивных числовых вычислений — TypedArray / примитивные массивы (V8/JVM) для лучшей оптимизации и векторизации.
- Использовать final (JVM) там, где помогает девиртуализации; избегать рефлексии/динамической генерации кода в hot paths.
4) Практики, которые мешают JIT
- Частая смена типов на одном call site (полиморфизм > monomorphic) — приводит к мегаполиморфизму и отказу от эффективных inline caches.
- Динамическое изменение структуры объектов (добавление/удаление полей в рантайме) — ломает hidden classes (V8).
- Использование eval / with / Proxy / динамической модификации прототипа — мешает оптимизациям.
- Частые деоптимизации: код, который часто нарушает предположения (меняет типы, выбрасывает исключения) — вызывает перекомпиляции.
- Большие методы с множеством ветвлений — могут не встраиваться (inlining budget).
- Холодные или одноразовые сценарии — JIT-накладные расходы не окупаются (cold-start).
- Интенсивные аллокации объектов в hot loop, когда escape analysis не применима — повышенная GC-накладка.
- Использование boxed-типов, отражений, synchronized/try/catch в tight loops (избегайте в hot paths).
5) Практические советы
- Профилируйте: измеряйте на реальных нагрузках; смотрите трассы компиляции/деоптаций (V8: --trace-deopt/--trace-opt; Node flags; JVM: -XX:+PrintCompilation, -XX:+PrintInlining, JFR).
- Оптимизируйте горячие участки по результатам профайла, не заранее.
- Делайте код понятным: простая предсказуемая структура часто выигрывает от JIT больше, чем «крутая» микрооптимизация.
Если нужно — могу привести короткий чек-лист для V8 и JVM или примеры паттернов, которые приводят к деоптам.