Да, к сожалению, такое ощущение, что здесь есть какое-то недопонимание. Я постараюсь уточнить ряд вопросов, касающихся производительности и GraalVM, здесь.
GraalVM - это среда выполнения полиглота, которая может запускать приложения JVM, обычно это происходит путем запуска Java HotSpot VM (например, OpenJDK JDK) с оптимизацией верхнего уровня JIT-компилятор заменен собственным компилятором GraalVM. Несколько упрощая, во время выполнения JVM загружает файлы классов, проверяет их, начинает их интерпретировать, а затем компилирует их с помощью серии компиляторов, которые стремятся к go от самой быстрой до компиляции до наиболее оптимизирующей - тем дольше приложение запускается и больше вы используете одни и те же методы - они постепенно компилируются в лучший и лучший машинный код.
Компилятор GraalVM действительно хорош в оптимизации кода, поэтому, когда ваше приложение запускается достаточно времени и оно начинает работать, результат обычно лучше, чем могут показывать другие компиляторы. Это приводит к лучшей пиковой производительности, которая отлично подходит для ваших средних / длительных рабочих нагрузок.
Ваш модульный тест занимает 2 секунды, что на самом деле не так много времени для выполнения кода, сбора профиля и использования оптимизирующего компилятора. Возможно также, что конкретные шаблоны кода и рабочая нагрузка действительно хорошо подходят для C2 (JIT верхнего уровня HotSpot по умолчанию), поэтому трудно быть лучше. Помните, C2 - это отличный JIT, который разрабатывался в течение как минимум двух десятилетий, и его результаты действительно очень хороши.
Теперь есть еще один вариант, который GraalVM предоставляет вам - Собственные изображения GraalVM , который позволяет вам заранее скомпилировать код (AOT) в собственный двоичный файл, который не будет зависеть от JVM и не будет загружать классы, проверять их, инициализировать их, поэтому запуск такого двоичного файла, пока он не станет полезным «деловая» работа намного лучше. Это очень интересный вариант для более коротких рабочих нагрузок или сред с ограниченными ресурсами (двоичный файл не нуждается в JIT-компиляции, поэтому ему не нужны ресурсы, что уменьшает потребление ресурсов времени выполнения). Однако, чтобы использовать этот подход, вам необходимо скомпилировать ваше приложение с помощью встроенной графической утилиты от GraalVM, и это может занять больше времени, чем ваша рабочая нагрузка, которая выполняется за 2 секунды.
Теперь в описываемой вами настройке вы не используете дистрибутив GraalVM, но включаете компилятор GraalVM в вашем дистрибутиве OpenJDK (я полагаю). Заданные вами параметры включают компилятор GraalVM в качестве JIT-компилятора верхнего уровня. В игре есть 2 основных отличия от того, что вы получите, запустив java из дистрибутива GraalVM:
- Компилятор не обновлен, в какой-то момент GraalVM исходники компилятора включаются в проект OpenJDK, и вот как он заканчивается в вашем дистрибутиве.
- Компилятор GraalVM написан на Java, и в вашей настройке он выполняется как обычный Java код, поэтому сначала может потребоваться JIT-компиляция, что приводит к более длительной фазе прогона прогона, несколько загрязненный JIT-профиль с его кодом, et c.
В дистрибутиве GraalVM, который я бы рекомендовал вам попробовать для этого эксперимента - компилятор GraalVM запущен - на сегодняшний день и по умолчанию предварительно скомпилирована в виде разделяемой библиотеки с использованием собственной технологии изображений GraalVM, поэтому во время выполнения ее не нужно компилировать JIT, поэтому ее прогрев намного больше похож на характеристики C2.
Тем не менее, 2 секунды может не хватить времени для оптимизирующего компилятора, чтобы показать основные различия. Может также случиться, что тесты запускают много кода один раз, и тело горячего кода, который скомпилирован JIT, не является достаточно значительным.