Хабрахабр

Guava, Graal и Partial Escape Analysis

На прошлой неделе случился релиз десятки — и хотя Graal был доступен и раньше, теперь он стал ещё доступней — Congratulations, you're running #Graal! — просто добавьте

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

Что конкретно это может нам дать и где можно ожидать улучшений, и какие велосипеды надо начинать выпиливать?

Пример, который я буду рассматривать — частично надуманный, однако, основанный на реальных событиях.

Guava

Наверняка многие используют класс Preconditions из библиотеки guava:

checkArgument(value > 0, "Non-negative value is expected, was %s", value);

И всё было бы хорошо, если бы подобный кусок не попадался на критическом пути в коде — проблема в неявном создании мусора.

Так выглядит тело метода checkArgument :

 public static void checkArgument( boolean expression, @Nullable String errorMessageTemplate, @Nullable Object... errorMessageArgs) { if (!expression) { throw new IllegalArgumentException(format(errorMessageTemplate, errorMessageArgs)); } }

Сделаем же неявное явным:

boolean expression = value > 0;
Object[] errorMessageArgs = new Object[]{Integer.valueOf(value)};
if (!expression) { throw new IllegalArgumentException(format(errorMessageTemplate, errorMessageArgs));
}

Здесь возникает дялемма шашечки-или ехать: Как правило похожие проверки в production коде это перестаховки, и с одной стороны не хочется за них платить дополнительным мусором, но с другой стороны fast fail не хочется выбрасывать.

Проблема в объектах порождаемых autoboxing и varargs, которые могут быть не использованы. Увы, но сталкиваясь с ветвлением Escape Analysis уже не в состоянии определить объект как ненужый.

Как можно решить проблему?

Например, перегрузив метод checkArgument (что в общем-то и сделано в guava):

 public static void checkArgument(boolean expression, @Nullable String errorMessageTemplate, int p1) { if (!expression) { throw new IllegalArgumentException(format(errorMessageTemplate, p1)); } }

Но, что если у нас не один аргумент, а больше двух — для которых есть перегруженные методы в guava? Писать свой костыль, либо страдать от мусора? В нашем коде мы столкнулись с местом, которое содержит комбинацию из 3х int, одной строки, которое выполняется миллионы раз и время отклика ограничено.

Graal

Java 10 и -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

Graal несёт на себе множество новых оптимизаций, и в частности Partial Escape Analysis — суть которого, среди прочего, заключается в том, что он в состоянии определить, что созданные объекты используются только в одном из ветвлении — и можно переместить создание этих объектов внутрь него.

Момент истины — какие ваши доказательства?

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(1)
@Warmup(iterations = 5, time = 5000, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 5, time = 5000, timeUnit = TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
public class PartialEATest { @Param(value = {"-1", "1"}) private int value; @Benchmark public void allocate(Blackhole bh) { checkArg(bh, value > 0, "expected non-negative value: %s, %s", value, 1000, "A", 700); } private static void checkArg(Blackhole bh, boolean cond, String msg, Object ... args){ if (!cond){ bh.consume(String.format(msg, args)); } } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(PartialEATest.class.getSimpleName()) .addProfiler(GCProfiler.class) .build(); new Runner(opt).run(); }
}

Из всех цифр нас интересуют аллокации — именно поэтому включил GCProfiler :

Options Benchmark (value) Score Error Units
-Graal PartialEATest.allocate:·gc.alloc.rate.norm -1 1008,000 ± 0,001 B/op
-Graal PartialEATest.allocate:·gc.alloc.rate.norm 1 32,000 ± 0,001 B/op
+Graal PartialEATest.allocate:·gc.alloc.rate.norm -1 1024,220 ± 0,908 B/op
+Graal PartialEATest.allocate:·gc.alloc.rate.norm 1 ≈ 10⁻⁴ B/op

Что вполне наглядно демонстрирует, что Graal не создает объекты без надобности.

Показать больше

Похожие публикации

Кнопка «Наверх»