java - MethodHandles 还是 LambdaMetafactory？

Question

在我的工作中，我们有一个用于指定数学公式的 DSL，我们后来将其应用于很多点(以百万计)。

截至今天，我们构建了公式的 AST，并访问每个节点以生成我们所谓的“评估器”。然后，我们将公式的参数传递给评估器，并针对每个点进行计算。

例如，我们有这个公式:x * (3 + y)

           ┌────┐
     ┌─────┤mult├─────┐
     │     └────┘     │
     │                │
  ┌──v──┐          ┌──v──┐
  │  x  │      ┌───┤ add ├──┐
  └─────┘      │   └─────┘  │
               │            │
            ┌──v──┐      ┌──v──┐
            │  3  │      │  y  │
            └─────┘      └─────┘

我们的评估器将为每个步骤发出“评估”对象。

这种方法编程容易，但效率不高。

所以我开始研究方法句柄以构建一个“组合”方法句柄以加快最近的速度。

一些事情:我有我的“算术”课:

public class Arithmetics {

  public static double add(double a, double b){
      return a+b;
  }

  public static double mult(double a, double b){
      return a*b;
  }

}

在构建我的 AST 时，我使用 MethodHandles.lookup() 来直接获取它们的句柄并组合它们。沿着这些线的东西，但在树上:

Method add = ArithmeticOperator.class.getDeclaredMethod("add", double.class, double.class);
Method mult = ArithmeticOperator.class.getDeclaredMethod("mult", double.class, double.class);
MethodHandle mh_add = lookup.unreflect(add);
MethodHandle mh_mult = lookup.unreflect(mult);
MethodHandle mh_add_3 = MethodHandles.insertArguments(mh_add, 3, plus_arg);
MethodHandle formula = MethodHandles.collectArguments(mh_mult, 1, mh_add_3); // formula is f(x,y) = x * (3 + y)

遗憾的是，我对结果感到非常失望。例如，方法句柄的实际构造非常长(由于调用 MethodHandles::insertArguments 和其他此类组合函数)，并且为评估增加的加速仅在超过 600k 次迭代后才开始产生影响。

在 1000 万次迭代时，方法句柄开始真正发挥作用，但数百万次迭代还不是(还？)典型用例。我们大约在 10k-1M 左右，结果好坏参半。

此外，实际计算速度加快了，但速度没有那么快(约 2-10 倍)。我期待它运行得更快一些..

所以无论如何，我再次开始搜索 StackOverflow，并看到了像这样的 LambdaMetafactory 线程:https://stackoverflow.com/a/19563000/389405

我很想开始尝试这个。但在此之前，我希望您能就一些问题发表意见:

• 我需要能够编写所有这些 lambda。 MethodHandles 提供了很多(缓慢的，公认的)方法来做到这一点，但我觉得 lambdas 有一个更严格的“接口(interface)”，我还不能全神贯注于如何做到这一点。你知道怎么做吗？

• lambda 和方法句柄相互关联，我不确定我是否会获得显着的加速。我看到这些简单 lambda 的结果:direct: 0,02s, lambda: 0,02s, mh: 0,35s, reflection: 0,40 但是组合 lambda 呢？

谢谢大家!

Answer 1

我认为，对于大多数实际情况，由满足特定接口(interface)或从公共(public)评估器基类继承的节点组成的不可变评估树是无与伦比的。 HotSpot 能够执行(积极的)内联，至少对于子树而言，但可以自由决定内联多少节点。

相比之下，为整个树生成显式代码会带来超过 JVM 阈值的风险，然后，您的代码肯定没有分派(dispatch)开销，但可能会一直解释运行。

适应的 MethodHandle 树像任何其他树一样开始，但开销更高。它自己的优化是否能够击败 HotSpots 自己的内联策略，是值得商榷的。正如您所注意到的，在自调整开始之前需要大量的调用。对于组合方法句柄来说，阈值似乎以一种不幸的方式累积。

举一个评估树模式的突出例子，当你使用 Pattern.compile 时准备正则表达式匹配操作，不会生成字节码或 native 代码，尽管该方法的名称可能会误导人们朝那个方向思考。内部表示只是一个不可变的节点树，表示不同类型操作的组合。 JVM 优化器会在认为有利的地方为其生成扁平化代码。

Lambda 表达式不会改变游戏规则。它们允许您生成(小)类来实现接口(interface)并调用目标方法。您可以使用它们来构建一个不可变的评估树，虽然这不太可能与显式编程的评估节点类有不同的性能，但它允许更简单的代码:

public class Arithmetics {
    public static void main(String[] args) {
        // x * (3 + y)
        DoubleBinaryOperator func=op(MUL, X, op(ADD, constant(3), Y));
        System.out.println(func.applyAsDouble(5, 4));
        PREDEFINED_UNARY_FUNCTIONS.forEach((name, f) ->
            System.out.println(name+"(0.42) = "+f.applyAsDouble(0.42)));
        PREDEFINED_BINARY_FUNCTIONS.forEach((name, f) ->
            System.out.println(name+"(0.42,0.815) = "+f.applyAsDouble(0.42,0.815)));
        // sin(x)+cos(y)
        func=op(ADD,
            op(PREDEFINED_UNARY_FUNCTIONS.get("sin"), X),
            op(PREDEFINED_UNARY_FUNCTIONS.get("cos"), Y));
        System.out.println("sin(0.6)+cos(y) = "+func.applyAsDouble(0.6, 0.5));
    }
    public static DoubleBinaryOperator ADD = Double::sum;
    public static DoubleBinaryOperator SUB = (a,b) -> a-b;
    public static DoubleBinaryOperator MUL = (a,b) -> a*b;
    public static DoubleBinaryOperator DIV = (a,b) -> a/b;
    public static DoubleBinaryOperator REM = (a,b) -> a%b;

    public static <T> DoubleBinaryOperator op(
        DoubleUnaryOperator op, DoubleBinaryOperator arg1) {
        return (x,y) -> op.applyAsDouble(arg1.applyAsDouble(x,y));
    }
    public static DoubleBinaryOperator op(
        DoubleBinaryOperator op, DoubleBinaryOperator arg1, DoubleBinaryOperator arg2) {
        return (x,y)->op.applyAsDouble(arg1.applyAsDouble(x,y),arg2.applyAsDouble(x,y));
    }
    public static DoubleBinaryOperator X = (x,y) -> x, Y = (x,y) -> y;
    public static DoubleBinaryOperator constant(double value) {
        return (x,y) -> value;
    }

    public static final Map<String,DoubleUnaryOperator> PREDEFINED_UNARY_FUNCTIONS
        = getPredefinedFunctions(DoubleUnaryOperator.class,
            MethodType.methodType(double.class, double.class));
    public static final Map<String,DoubleBinaryOperator> PREDEFINED_BINARY_FUNCTIONS
        = getPredefinedFunctions(DoubleBinaryOperator.class,
            MethodType.methodType(double.class, double.class, double.class));

    private static <T> Map<String,T> getPredefinedFunctions(Class<T> t, MethodType mt) {
        Map<String,T> result=new HashMap<>();
        MethodHandles.Lookup l=MethodHandles.lookup();
        for(Method m:Math.class.getMethods()) try {
            MethodHandle mh=l.unreflect(m);
            if(!mh.type().equals(mt)) continue;
            result.put(m.getName(), t.cast(LambdaMetafactory.metafactory(
            MethodHandles.lookup(), "applyAsDouble", MethodType.methodType(t),
            mt, mh, mt) .getTarget().invoke()));
        }
        catch(RuntimeException|Error ex) { throw ex; }
        catch(Throwable ex) { throw new AssertionError(ex); }
        return Collections.unmodifiableMap(result);
    }
}

这是为由 java.lang.Math 中的基本算术运算符和函数组成的表达式编写求值器所需的一切，后者是动态收集的，以解决您问题的这一方面。

请注意，从技术上讲，

public static DoubleBinaryOperator MUL = (a,b) -> a*b;

只是

的简写

public static DoubleBinaryOperator MUL = Arithmetics::mul;
public static double mul(double a, double b){
    return a*b;
}

我添加了一个包含一些示例的 main 方法。请记住，这些函数在第一次调用时表现得像编译代码，事实上，它们仅由编译代码组成，但由多个函数组成。