Как создать native image с помощью GraalVM

Про GraalVM я уже рассказывал в предыдущей статье. Из набора технологий GraalVM интересным была технология предварительной компиляции Ahead-of-Time compilation (AOT compilation), которая была на время экспериментально добавлена в обычный Java JDK. В Java 17 эта функция была выпилена. Ходят слухи, что в Java 21 она снова появится.

В GraalVM функция предкомпиляции позволяет так называемые нативные приложения (native images). То есть все ваше Java-приложение вместе со всеми потрохами Java SDK заворачивается в исполняемый файл и этот файл можно запускать, на любой другой машине даже если там нет Java JDK. Разумеется, exe-файл получается внушительный, но 1) GraalVM весьма умно при компиляции понимает, что надо в него заворачивать, а что не понадобится 2) когда это нас стали пугать exe файлы размером в 11 мегабайт?

Давно хотел поиграться с этой функцией, чтобы хотя бы в общих чертах понять сам процесс. Я решил попробовать собрать простейшее тестовое Spring-приложение в native-image не меняя в нем ничего, чтобы разобраться, какие танцы с бубном понадобятся, чтобы все заработало само собой просто из коробки.

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

Собрать библиотеку hsdis для просмотра ассемблерного кода. Насколько глубока кроличья нора?

Библиотека hsdis удобна для преобразования листинга машинного кода, создаваемого JIT-компилятором, в читаемый ассемблерный код. Просмотр ассемблерных инструкций может пригодиться для проверки и отладки какого-то критического участка кода, который, например, чувствителен к latency.

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

Как посмотреть, что и как компилирует JIT-компилятор?

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

Новый JIT-компилятор Graal

Как уже говорилось в предыдущих статьях, в JVM HotSpot имеется два JIT-компилятора: C1 и C2. Первый компилятор — клиентский (client), который быстренько компилирует код при старте и первых минутах работы JVM, потом некоторое время собирает статистику по работе приложения, после чего в дело вступает компилятор C2 — серверный (server) — который делает более глубокие оптимизации и создает более быстрый машинный код.

JIT-компилятор и как он нам поможет победить latency

JIT-компилятор — встроенный в JVM компилятор байткода в машинный код. Проведя множество интервью с кандидатами на роль Core Java Developer, я был удивлен тем, что многие кандидаты даже не подозревали о существовании такой технологии в JVM, а те, кто краем уха что-то слышал, не могли объяснить, как она работает. Может быть для написания J2EE или веб-приложений этих знаний и не требуется, но для работы в области low-latency trading эти знания — ключевые.

Описание JIT-компилятора хорошо дано в книгах:

• (2014) Java Performance — The Definitive Guide (ISBN 1449358454) — Scott Oaks — гл.4: Working with the JIT Compiler
• (2018) Optimizing Java — Practical Techniques for Improving JVM Application Performance (ISBN 1492025798) — Ben Evans, James (Jim) Gough, Chris Newland — глава HotSpot JIT Basics

В данной статье я просто изложу основы, без знания которых непонятны будут другие статьи по low-latency оптимизации JVM.