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

TL; DR: вы не должны слепо доверять ничему.

прежде всего: важно проверить экспериментальные данные, прежде чем перейти к выводам из них. Просто утверждать, что что-то в 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    x30,%rsp         
 12.23%   16.00%    0x00007f5724aec10c: mov    x2a,%eax   ; load "42"
  0.95%    0.97%    0x00007f5724aec111: add    x30,%rsp
           0.02%    0x00007f5724aec115: pop    %rbp
 37.94%   54.70%    0x00007f5724aec116: test   %eax,0x10d1aee4(%rip)        
  0.04%    0.02%    0x00007f5724aec11c: retq  

ref:

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

[сарказм] смотрите, как это просто! [/сарказм]

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