О динамической деоптимизации HotSpot

Oracle предоставляет (довольно краткий) обзор этих методов повышения производительности, применяемых JVM . Это объясняет:

Деоптимизация — это процесс замены оптимизированного кадра стека на неоптимизированный. Что касается скомпилированных методов, это также процесс отбрасывания кода с недопустимыми оптимистичными оптимизациями и замены его менее оптимизированным, более надежным кодом. Метод в принципе может быть деоптимизирован десятки раз.

В этом резюме причины деоптимизации перечислены ниже:

1. Компилятор может заглушить невыполненную ветвь и деоптимизировать ее, если она когда-либо будет взята.
2. Аналогично для низкоуровневых проверок безопасности, которые исторически никогда не подводили.
3. Если сайт вызова или приведение встречают непредвиденный тип, компилятор деоптимизирует.
4. Если загружается класс, который делает недействительным более ранний анализ иерархии классов, все задействованные активации методов в любом потоке принудительно переводятся в точку безопасности и деоптимизируются.
5. Такая косвенная деоптимизация опосредована системой зависимостей. Если компилятор делает непроверенное предположение, он должен зарегистрировать проверяемую зависимость. (Например, этот класс Foo не имеет подклассов или метод Foo.bar не имеет переопределений.)

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

Оптимизация HotSpot отличается от того, что разработчики делают на уровне исходного кода Java, хотя некоторые из них имеют тот же общий эффект.

Это часть арсенала компилятора JIT:

• встраивание вызова метода;
• подъем значений из цикла;
• мономорфные сайты вызовов;
• размещение объектов в стеке, подлежащих анализу побега;
• привязка переменных к регистрам процессора;
• блокировка элизии.

Самая интересная часть — это синергия между некоторыми оптимизациями, такими как:

1. сайт вызова реализован как мономорфный;
2. это позволяет встраивать методы;
3. который предлагает размещение объекта в стеке;
4. что позволяет привязывать поля объекта к регистрам.

Ваша цитата, однако, насколько мне известно, неверна. Оптимизированный код не занимается самопрофилированием, потому что это замедлит его работу. Единственным условием деоптимизации является нарушение оптимистичных предположений, при которых код был JIT-компилирован. Пример: данный сайт вызова метода получает только один тип объекта, специализированный для этого объекта (компилируется как мономорфный сайт вызова), но затем, позже, появляется другой тип объекта. Теперь оптимизированный код не может быть выполнен и должен быть деоптимизирован.

«Оптимизация компилятора» — это преобразование кода в попытке сделать его лучше в каком-то смысле — обычно это требует меньше времени для выполнения. статья Википедии об оптимизации компиляторов содержит хороший список распространенных оптимизаций; компилятор Hotspot JIT, вероятно, делает все это и даже больше.

Таким образом, книга означает, что Hotspot применит некоторые из этих методов к коду, посмотрит, улучшит ли это время выполнения, и если нет, вернет его обратно.

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