Почему возвращает ссылку на объект Java намного медленнее, чем возвращение примитива

Мы работаем над чувствительным к задержкам приложением и проводим микробизнес-анализ всех видов методов (используя jmh). После microbenchmarking метода поиска и удовлетворения результатов, я внедрил окончательную версию, только чтобы найти, что окончательная версия была в 3 раза медленнее, чем то, что я только что тестировал.

Виной было то, что реализованный метод возвращал объект enum вместо int. Вот упрощенная версия эталонного кода:

@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Thread)
public class ReturnEnumObjectVersusPrimitiveBenchmark {

    enum Category {
        CATEGORY1,
        CATEGORY2,
    }

    @Param( {"3", "2", "1" })
    String value;

    int param;

    @Setup
    public void setUp() {
        param = Integer.parseInt(value);
    }

    @Benchmark
    public int benchmarkReturnOrdinal() {
        if (param < 2) {
            return Category.CATEGORY1.ordinal();
        }
        return Category.CATEGORY2.ordinal();        
    }


    @Benchmark
    public Category benchmarkReturnReference() {
        if (param < 2) {
            return Category.CATEGORY1;
        }
        return Category.CATEGORY2;      
    }


    public static void main(String[] args) throws RunnerException {
            Options opt = new OptionsBuilder().include(ReturnEnumObjectVersusPrimitiveBenchmark.class.getName()).warmupIterations(5)
                .measurementIterations(4).forks(1).build();
        new Runner(opt).run();
    }

}

Результаты тестов выше:

# VM invoker: C:\Program Files\Java\jdk1.7.0_40\jre\bin\java.exe
# VM options: -Dfile.encoding=UTF-8

Benchmark                   (value)   Mode  Samples     Score     Error   Units
benchmarkReturnOrdinal            3  thrpt        4  1059.898 ±  71.749  ops/us
benchmarkReturnOrdinal            2  thrpt        4  1051.122 ±  61.238  ops/us
benchmarkReturnOrdinal            1  thrpt        4  1064.067 ±  90.057  ops/us
benchmarkReturnReference          3  thrpt        4   353.197 ±  25.946  ops/us
benchmarkReturnReference          2  thrpt        4   350.902 ±  19.487  ops/us
benchmarkReturnReference          1  thrpt        4   339.578 ± 144.093  ops/us

Простое изменение возвращаемого типа функции изменило производительность почти в 3 раза.

Я думал, что единственная разница между возвратом объекта enum и целым числом состоит в том, что один возвращает 64-битное значение (ссылка), а другое возвращает 32-битное значение. Один из моих коллег предполагал, что возвращение enum добавило дополнительные накладные расходы из-за необходимости отслеживать ссылку для потенциального GC. (Но, учитывая, что объекты перечисления являются статическими окончательными ссылками, кажется странным, что это нужно будет сделать).

В чем объясняется разница в производительности?


ОБНОВЛЕНИЕ

Я поделился проектом maven здесь, чтобы каждый мог клонировать его и запускать тест. Если у кого есть время/интерес, было бы полезно посмотреть, смогут ли другие реплицировать те же результаты. (Я реплицировал на 2 разных компьютерах, Windows 64 и Linux 64, используя оба варианта JVM Oracle Java 1.7). @ZhekaKozlov говорит, что он не видел никакой разницы между этими методами.

Для запуска: (после клонирования репозитория)

mvn clean install
java -jar .\target\microbenchmarks.jar function.ReturnEnumObjectVersusPrimitiveBenchmark -i 5 -wi 5 -f 1

Ответ 1

TL; DR: вы не должны накладывать доверие BLIND.

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

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

До точки. На моей машине (i5-4210U, Linux x86_64, JDK 8u40) тест дает:

Benchmark                    (value)   Mode  Samples  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt        5  0.876 ± 0.023  ops/ns
...benchmarkReturnOrdinal          2  thrpt        5  0.876 ± 0.009  ops/ns
...benchmarkReturnOrdinal          1  thrpt        5  0.832 ± 0.048  ops/ns
...benchmarkReturnReference        3  thrpt        5  0.292 ± 0.006  ops/ns
...benchmarkReturnReference        2  thrpt        5  0.286 ± 0.024  ops/ns
...benchmarkReturnReference        1  thrpt        5  0.293 ± 0.008  ops/ns

Хорошо, поэтому эталонные тесты появляются на 3 раза медленнее. Но подождите, он использует старый JMH (1.1.1), пусть обновляется до последней версии (1.7.1):

Benchmark                    (value)   Mode  Cnt  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt    5  0.326 ± 0.010  ops/ns
...benchmarkReturnOrdinal          2  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnOrdinal          1  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnReference        3  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        2  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        1  thrpt    5  0.288 ± 0.002  ops/ns

Ой, теперь они только медленнее. Кстати, это также говорит нам, что тест связан с инфраструктурой. Хорошо, можем ли мы увидеть, что на самом деле происходит?

Если вы создадите тесты и посмотрите, что именно называет ваши методы @Benchmark, вы увидите что-то вроде:

public void benchmarkReturnOrdinal_thrpt_jmhStub(InfraControl control, RawResults result, ReturnEnumObjectVersusPrimitiveBenchmark_jmh l_returnenumobjectversusprimitivebenchmark0_0, Blackhole_jmh l_blackhole1_1) throws Throwable {
    long operations = 0;
    long realTime = 0;
    result.startTime = System.nanoTime();
    do {
        l_blackhole1_1.consume(l_longname.benchmarkReturnOrdinal());
        operations++;
    } while(!control.isDone);
    result.stopTime = System.nanoTime();
    result.realTime = realTime;
    result.measuredOps = operations;
}

Этот l_blackhole1_1 имеет метод consume, который "потребляет" значения (см. Blackhole для обоснования). Blackhole.consume имеет перегрузки для ссылки и примитивы, и что один достаточно, чтобы оправдать разницу в производительности.

Существует логическое обоснование того, почему эти методы выглядят по-разному: они стараются быть как можно быстрее для своих типов аргументов. Они не обязательно демонстрируют одни и те же характеристики производительности, хотя мы стараемся их сопоставить, следовательно, более симметричный результат с более новым JMH. Теперь вы можете даже перейти к -prof perfasm, чтобы увидеть сгенерированный код для своих тестов и посмотреть, почему производительность отличается, но это не следует здесь.

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

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(5)
public class PrimVsRef {

    @Benchmark
    public void prim() {
        doPrim();
    }

    @Benchmark
    public void ref() {
        doRef();
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private int doPrim() {
        return 42;
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private Object doRef() {
        return this;
    }

}

..., который дает тот же результат для примитивов и ссылок:

Benchmark       Mode  Cnt  Score   Error  Units
PrimVsRef.prim  avgt   25  2.637 ± 0.017  ns/op
PrimVsRef.ref   avgt   25  2.634 ± 0.005  ns/op

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

чопорная:

                  [Verified Entry Point]
 12.69%    1.81%    0x00007f5724aec100: mov    %eax,-0x14000(%rsp)
  0.90%    0.74%    0x00007f5724aec107: push   %rbp
  0.01%    0.01%    0x00007f5724aec108: sub    $0x30,%rsp         
 12.23%   16.00%    0x00007f5724aec10c: mov    $0x2a,%eax   ; load "42"
  0.95%    0.97%    0x00007f5724aec111: add    $0x30,%rsp
           0.02%    0x00007f5724aec115: pop    %rbp
 37.94%   54.70%    0x00007f5724aec116: test   %eax,0x10d1aee4(%rip)        
  0.04%    0.02%    0x00007f5724aec11c: retq  

ссылка

                  [Verified Entry Point]
 13.52%    1.45%    0x00007f1887e66700: mov    %eax,-0x14000(%rsp)
  0.60%    0.37%    0x00007f1887e66707: push   %rbp
           0.02%    0x00007f1887e66708: sub    $0x30,%rsp         
 13.63%   16.91%    0x00007f1887e6670c: mov    %rsi,%rax     ; load "this"
  0.50%    0.49%    0x00007f1887e6670f: add    $0x30,%rsp
  0.01%             0x00007f1887e66713: pop    %rbp
 39.18%   57.65%    0x00007f1887e66714: test   %eax,0xe3e78e6(%rip)
  0.02%             0x00007f1887e6671a: retq   

[сарказм] Посмотрите, как легко! [/Сарказм]

Образец: чем проще вопрос, тем больше вы должны работать, чтобы сделать правдоподобный и надежный ответ.

Ответ 2

Чтобы очистить неверное представление о ссылке и памяти, некоторые из них попали (@Mzf), дайте возможность погрузиться в спецификацию виртуальной машины Java. Но прежде чем отправиться туда, нужно уточнить одно: объект никогда не может быть извлечен из памяти, только его поля могут. Фактически, нет кода операции, который бы выполнял такую ​​обширную операцию.

Этот документ определяет ссылку как тип типа стека (так, чтобы он мог быть результатом или аргументом для команд, выполняющих операции над стеком) 1-й категории - категории типов, принимающих одно слово стека ( 32 бита). См. Таблицу 2.3 A list of Java Stack Types.

Кроме того, если вызов метода завершается, как правило, в соответствии со спецификацией, значение, вставленное из верхней части стека, помещается в стек вызывающего метода (раздел 2.6.4).

Ваш вопрос вызывает разницу во времени выполнения. Глава 2 ответы на предисловие:

Сведения о реализации, которые не входят в спецификацию Java Virtual Machine будет излишне ограничивать творчество разработчиков. Например, макет памяти областей данных во время выполнения, используемый алгоритм сбора мусора и любая внутренняя оптимизация инструкций виртуальной машины Java (например, перевод их в машинный код) оставляются на усмотрение разработчика.

Другими словами, поскольку в логическом отношении в документе не указывается кадровое наказание за использование ссылки (в конечном итоге это просто слово стека как int или float), вы остаетесь с поиск исходного кода вашей реализации или вообще не обнаружение.

В степени, мы не должны на самом деле всегда обвинять реализацию, есть некоторые подсказки, которые вы можете предпринять, когда ищете свои ответы. Java определяет отдельные инструкции для обработки чисел и ссылок. Инструкции по эталонному манипулированию начинаются с a (например, astore, aload или areturn) и являются единственными инструкциями, разрешенными для работы со ссылками. В частности, вам может быть интересно посмотреть на реализацию areturn.