HotSpot 可以优化掉对纯方法的冗余调用而不内联它们吗？答案

【问题标题】：Can HotSpot optimize away redundant calls to pure methods without inlining them?HotSpot 可以优化掉对纯方法的冗余调用而不内联它们吗？
【发布时间】：2018-06-11 08:13:37
【问题描述】：

Pure methods 是那些没有副作用的：它们唯一的作用是返回一个作为其参数函数的值。

使用相同参数两次调用相同的纯方法将返回相同的值。那么，给定对具有相同参数的纯方法的两次调用，HotSpot 是否可以优化第二次调用，只需重新使用第一次调用的值？

例如：

int add(int x, int y) {
  return x + y;
}

int addTwice(int x, int y) {
  return add(x, y) + add(x, y);
}

如果 HotSpot 没有将 add 内联到 addTwice 中，它是否理解 add 是纯并因此只调用一次 add 并将返回值加倍？

当然，这种微不足道的 [mcve] 不太可能引起直接兴趣，但由于内联、不同的控制流、自动生成的代码等，在实践中可能会发生类似的情况。

【问题讨论】：

Java HotSpot Performance Engine Architecture 似乎没有提到纯方法检测。如果存在，我希望这样的功能会被突出显示。
@JimGarrison - 是的，尽管公平地说，这是一个非常高级的概述，只明确提到了五种重要技术。即使确实存在纯方法检测，我认为这将是从被包含在这样的列表中删除的几个级别的模糊（尽管他们提到的快速“instanceof”东西非常模糊）。 Here's a somewhat dated but more comprehensive list 也没有提到纯方法检测。
考虑到纯方法结果缓存的优化潜力，如果没有提到它，我会感到惊讶:-)
Hiotspot 可以做任何在 JLS 和 JVM 规范规则下无法观察到的事情。
@Quonux - 当然，但 JIT 也可以使用更宽松的纯定义：如果当前编译的版本是纯的，它可以考虑一个函数条件纯，考虑不常见陷阱是纯的，即使整个函数不是纯的。例如，如果一个函数包含编译前在实践中从未观察到的不纯行为（例如，登录错误处理路径），JIT 通常会选择根本不编译未采用的分支，而只是插入一个不常见的陷阱覆盖这种情况，如果它会强制重新编译函数。

标签： java compiler-optimization jvm-hotspot

【解决方案1】：

到目前为止，HotSpot 无法做到这一点。

如果没有内联，则方法调用对于 JIT 编译器通常是不透明的。很难进行跨方法优化。原因之一是方法入口点是易变的，即由于 JIT 编译、重新编译、反优化、JVMTI 调用等，它可以在运行时同时更改。当 HotSpot 进行显式方法调用时，它不知道目标方法是解释还是编译，是否收集 JIT 统计信息，是否正在调试，内部是否有断点，或者是否启用了 JVMTI 方法事件。

另一方面，即使存在这样的优化，也不会太有用。纯方法的功能非常有限，因此它们通常简短而简单，并且有很多内联的机会。内联后，JIT 在同一编译范围内进行优化会容易得多。

【讨论】：

谢谢，这是有道理的（尤其是关于函数如何在纯和非纯之间变化的部分，具体取决于断点、JVMTI 等）。当你说入口点是 volatile 时，你的意思是被调用函数的实际入口点地址可以改变（例如，由于重新编译）还是只有函数的主体可以改变？如果我假设前者，那么波动性似乎并没有真正造成问题：因为如果入口点发生变化，无论如何都必须重新编译所有调用者，此时他们可以考虑新的“纯”状态，对?
@BeeOnRope 入口地址发生变化。调用者不必重新编译，因为该方法是通过间接调用而不是直接地址调用的。
谢谢。我确实在 C2 代码中看到了很多直接调用，但也许这些是针对其他类型的存根例程或运行时方法，而不是其他方法。
这个怎么样？ goertzel.org/papers/SupercompilingJavaMay2002.htm 。纯函数并不总是“微不足道的”。在（纯）函数式语言中，编写复杂的纯函数是很常见的。
我厌倦了这些编译器讨论中的这种内联、通用子表达式消除等以及其他标准主题！？产生超级编译器和超级优化器级别代码的编译器在哪里？