Почему Java быстрее при использовании JIT по сравнению с компиляцией в машинный код?

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

Если вы предварительно скомпилируете байт-код в машинный код, компилятор не сможет оптимизировать для целевой машины (ов), только для машины сборки.

Способность Java встраиваться через границы виртуальных методов и выполнять эффективную диспетчеризацию интерфейсов требует анализа времени выполнения перед компиляцией - другими словами, для этого требуется JIT. Поскольку все методы виртуальные, а интерфейсы используются «повсюду», это имеет большое значение.

Теоретически JIT-компилятор имеет преимущество перед AOT , если он имеет доступно достаточно времени и вычислительных ресурсов . Например, если у вас есть корпоративное приложение, работающее днями и месяцами на многопроцессорном сервере с большим количеством ОЗУ, JIT-компилятор может создать лучший код, чем любой компилятор AOT.

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

нет шансов против АОТ.

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

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

JIT-компилятор Java также ленив и адаптивен.

Ленивый

Из-за своей лени он компилирует методы только тогда, когда добирается до них, вместо компиляции всей программы (очень полезно, если вы этого не сделаете) t использовать часть программы). Загрузка классов на самом деле помогает ускорить JIT, позволяя игнорировать классы, с которыми он еще не сталкивался.

Адаптивный

Будучи адаптивным, он сначала генерирует быструю и грязную версию машинного кода, а затем только возвращается и выполняет сквозное задание, если этот метод используется часто.

JIT могут идентифицировать и устранять некоторые условия, которые могут быть известны только во время выполнения. Ярким примером является устранение виртуальных вызовов, используемых современными виртуальными машинами - например, когда JVM находит инструкцию invokevirtual или invokeinterface , если был загружен только один класс, переопределяющий вызываемый метод, Виртуальная машина действительно может сделать этот виртуальный вызов статическим и, таким образом, встроить его. С другой стороны, для программы на C указатель на функцию всегда является указателем на функцию, и ее вызов не может быть встроен (во всяком случае, в общем случае).

Вот ситуация, когда JVM может встроить виртуальный вызов:

interface I { 
    I INSTANCE = Boolean.getBoolean("someCondition")? new A() : new B();
    void doIt(); 
}
class A implements I { 
    void doIt(){ ... } 
}
class B implements I { 
    void doIt(){ ... } 
}
// later...
I.INSTANCE.doIt();

Предполагая, что мы не будем создавать экземпляры A или B где-либо еще и что someCondition имеет значение true , JVM знает, что вызов doIt () всегда означает A.doIt , и поэтому может избежать поиска в таблице методов, а затем встроить вызов. Подобная конструкция в среде без JITted не может быть встраиваемой.

Я думаю, что тот факт, что официальный компилятор Java является JIT-компилятором, является значительной частью этого. Сколько времени было потрачено на оптимизацию JVM по сравнению с компилятором машинного кода для Java?