Каковы различия в JIT между Java и .NET

Это очень разные звери. Как отмечали люди, CLR компилируется в машинный код перед выполнением части MSIL. Это позволяет в дополнение к типичному устранению мертвого кода и встраиванию оптимизаций частных лиц использовать преимущества конкретной архитектуры ЦП целевой машины (хотя я не уверен, делает ли она это). Это также приводит к поражению каждого класса (хотя компилятор работает довольно быстро, а многие библиотеки платформы представляют собой лишь тонкий слой над Win32 API).

Виртуальная машина HotSpot использует другой подход. В нем оговаривается, что большая часть кода выполняется редко, поэтому не стоит тратить время на его компиляцию. Весь байт-код запускается в интерпретируемом режиме. ВМ хранит статистику на сайтах вызовов и пытается идентифицировать методы, которые вызываются больше заранее определенного количества раз. Затем он компилирует только эти методы с помощью быстрого JIT-компилятора (C1) и меняет местами метод во время его работы (это особый соус HS).После того, как метод, скомпилированный с помощью C1, был вызван еще несколько раз, тот же метод компилируется медленным, но сложным компилятором, и код снова меняется местами на лету.

Поскольку HotSpot может менять местами методы во время их работы, компиляторы виртуальных машин могут выполнять некоторые предположительные оптимизации, которые небезопасны в статически скомпилированном коде. Канонический пример - статическая отправка / встраивание мономорфных вызовов (полиморфный метод только с одной реализацией). Это делается, если виртуальная машина видит, что этот метод всегда разрешает одну и ту же цель. То, что раньше было сложным вызовом, сокращается до нескольких защитных инструкций ЦП, которые предсказываются и обрабатываются современными ЦП. Когда условие защиты перестает быть истинным, виртуальная машина может выбрать другой путь кода или даже вернуться в режим интерпретации. Основываясь на статистике и загруженности программы, сгенерированный машинный код может отличаться в разное время. Многие из этих оптимизаций полагаются на информацию, собранную во время выполнения программы, и невозможны, если вы компилируете один раз после загрузки класса.

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

Тем не менее, HotSpot - это только одна из виртуальных машин. JRockit, Azul, IBM J9 и Resettable RVM - все имеют разные профили производительности.