JUG.EKB #7

В высокопроизводительных приложениях аллокация нередко становится одним из узких мест — если не непосредственно, то через увеличение нагрузки на GC. Написание же garbage-less кода в джаве требует нетривиальных усилий, код становится сложнее и менее понятным. Современные JIT-ы умеют, в некоторых случаях, самостоятельно стирать аллокации короткоживущих объектов, превращая их поля в набор эквивалентных локальных переменных. Эта оптимизация (скаляризация) появилась еще в версии 1.6, и с тех пор прошло уже 7 лет, но в открытых источниках удивительно мало деталей — где и когда эта оптимизация срабатывает, а где не срабатывает, насколько надежно она работает, и что может ей помешать.

Существуют различные реализации Java. В некоторых из них есть ahead-of-time (AOT) компиляторы, причём подход к решению различный, да и постановка задачи разная. В Hotspot есть JIT-компиляция, но нет стандартного AOT. Не обязательно, что так будет всегда.
Мы поговорим о том, зачем может понадобится заранее получать нативный код, как это делается и работает в реализации для Hotspot. И с другой стороны, как Java-код может встраиваться в процесс JIT-компиляции.