是否有可能使java.lang.invoke.MethodHandle与直接调用一样快？

performance java jit jvm jmh

2022-09-04 08:44:04

我正在比较性能和直接静态方法调用。下面是静态方法：MethodHandle::invoke

public class IntSum {
    public static int sum(int a, int b){
        return a + b;
    }
}

这是我的基准：

@State(Scope.Benchmark)
public class MyBenchmark {

    public int first;
    public int second;
    public final MethodHandle mhh;

    @Benchmark
    @OutputTimeUnit(TimeUnit.NANOSECONDS)
    @BenchmarkMode(Mode.AverageTime)
    public int directMethodCall() {
        return IntSum.sum(first, second);
    }

    @Benchmark
    @OutputTimeUnit(TimeUnit.NANOSECONDS)
    @BenchmarkMode(Mode.AverageTime)
    public int finalMethodHandle() throws Throwable {
        return (int) mhh.invoke(first, second);
    }

    public MyBenchmark() {
        MethodHandle mhhh = null;

        try {
            mhhh = MethodHandles.lookup().findStatic(IntSum.class, "sum", MethodType.methodType(int.class, int.class, int.class));
        } catch (NoSuchMethodException | IllegalAccessException e) {
            e.printStackTrace();
        }

        mhh = mhhh;
    }

    @Setup
    public void setup() throws Exception {
        first = 9857893;
        second = 893274;
    }
}

我得到了以下结果：

Benchmark                      Mode  Cnt  Score   Error  Units
MyBenchmark.directMethodCall   avgt    5  3.069 ± 0.077  ns/op
MyBenchmark.finalMethodHandle  avgt    5  6.234 ± 0.150  ns/op

MethodHandle有一些性能下降。

运行它显示：-prof perfasm

....[Hottest Regions]...............................................................................
 31.21%   31.98%         C2, level 4  java.lang.invoke.LambdaForm$DMH::invokeStatic_II_I, version 490 (27 bytes) 
 26.57%   28.02%         C2, level 4  org.sample.generated.MyBenchmark_finalMethodHandle_jmhTest::finalMethodHandle_avgt_jmhStub, version 514 (84 bytes) 
 20.98%   28.15%         C2, level 4  org.openjdk.jmh.infra.Blackhole::consume, version 497 (44 bytes)

据我所知，基准测试结果的原因是最热的区域 2 包含 JHM 循环内部执行的所有类型检查。程序集输出片段（省略了某些代码）：org.sample.generated.MyBenchmark_finalMethodHandle_jmhTest::finalMethodHandle_avgt_jmhStubMethodHandle::invoke

....[Hottest Region 2]..............................................................................
C2, level 4, org.sample.generated.MyBenchmark_finalMethodHandle_jmhTest::finalMethodHandle_avgt_jmhStub, version 519 (84 bytes) 
;...
0x00007fa2112119b0: mov     0x60(%rsp),%r10
;...
0x00007fa2112119d4: mov     0x14(%r12,%r11,8),%r8d  ;*getfield form
0x00007fa2112119d9: mov     0x1c(%r12,%r8,8),%r10d  ;*getfield customized
0x00007fa2112119de: test    %r10d,%r10d
0x00007fa2112119e1: je      0x7fa211211a65    ;*ifnonnull
0x00007fa2112119e7: lea     (%r12,%r11,8),%rsi
0x00007fa2112119eb: callq   0x7fa211046020    ;*invokevirtual invokeBasic
;...
0x00007fa211211a01: movzbl  0x94(%r10),%r10d  ;*getfield isDone
;...
0x00007fa211211a13: test    %r10d,%r10d
;jumping at the begging of jmh loop if not done
0x00007fa211211a16: je      0x7fa2112119b0    ;*aload_1 
;...

在调用之前，我们执行类型检查（在 jmh 循环内），这会影响输出 avgt。invokeBasic

问题：为什么不把所有的类型检查都移到循环之外？我在基准测试中声明。所以我期望编译器能够弄清楚并消除相同的类型检查。如何消除相同的类型检查？可能吗？public final MethodHandle mhh;

答案 1

使用 的反省调用。它的工作方式大致类似于，但运行时检查较少，并且没有装箱/取消装箱。由于这不是，JVM 不将其视为常量，也就是说，MethodHandle 的目标是一个黑匣子，无法内联。MethodHandleMethod.invokeMethodHandlestatic final

尽管是 final，但它包含实例字段，例如和在每次迭代时重新加载的实例字段。这些负载不会因为内部的黑盒调用而从循环中吊出（见上文）。此外，可以在调用之间的运行时更改（自定义），因此需要重新加载。mhhMethodType typeLambdaForm formLambdaFormMethodHandle

如何使呼叫更快？

使用方法处理。JIT 将知道此类方法处理的目标，因此可以在调用站点内联它。static final

即使您有非静态方法处理程序，也可以将其绑定到静态 CallSite，并像直接方法一样快速地调用它。这类似于 lambda 的调用方式。

private static final MutableCallSite callSite = new MutableCallSite(
        MethodType.methodType(int.class, int.class, int.class));
private static final MethodHandle invoker = callSite.dynamicInvoker();

public MethodHandle mh;

public MyBenchmark() {
    mh = ...;
    callSite.setTarget(mh);
}

@Benchmark
public int boundMethodHandle() throws Throwable {
    return (int) invoker.invokeExact(first, second);
}

使用常规而不是@Holger建议。用于调用给定方法处理的接口实例可以使用LambdaMetafactory.metafactory（）生成。invokeinterfaceMethodHandle.invoke

答案 2

设为静态：MethodHandle mhh

Benchmark            Mode  Samples  Score   Error  Units
directMethodCall     avgt        5  0,942 ± 0,095  ns/op
finalMethodHandle    avgt        5  0,906 ± 0,078  ns/op

非静态：

Benchmark            Mode  Samples  Score   Error  Units
directMethodCall     avgt        5  0,897 ± 0,059  ns/op
finalMethodHandle    avgt        5  4,041 ± 0,463  ns/op