关于HotSpot的动态解优化

Question

当我深入阅读"Scala“一书时，它提到HotSpot编译器有几个重要特性，其中之一是”动态去优化“：

它是一种能力，可以确定某个优化实际上是否提高了性能，并撤消了该优化，从而允许应用其他优化。

HotSpot似乎会尝试各种“优化”，并选择其中最好的一种。

但我不太明白。这里的“优化”都是由HotSpot提供的吗？我的意思是程序员经常尝试用一些技巧来优化代码，HotSpot会处理它们吗？

是否有任何常见的“优化”HotSpot会尝试？

Answer 1

Oracle提供了一个(相当简洁) JVM应用的这种性能技术的摘要。它解释说：

去优化是将优化的堆栈帧更改为未优化的堆栈帧的过程。对于编译的方法，它也是用无效的乐观优化丢弃代码，并以优化程度较低、更健壮的代码代替的过程。一种方法原则上可以去优化几十次。

在本摘要中，不优化的原因如下：

1. 编译器可能会存根出一个未取的分支，并对其进行优化。
2. 同样，对于历史上从未失败过的低级安全检查也是如此。
3. 如果调用站点或强制转换遇到意外类型，则编译器将进行优化。
4. 如果加载的类使以前的类层次结构分析无效，则任何线程中任何受影响的方法激活都会被强制到safepoint并进行去优化。
5. 这种间接去优化是由依赖系统介导的。如果编译器做了一个未经检查的假设，它必须注册一个可检查的依赖项。(例如，Foo类没有子类，或者方法Foo.bar is没有重写。)

就我个人而言，我发现微基准测试上的这个博客条目相当可读的，它也涵盖了HotSpot VM上的优化和去优化的主题。此外，我还可以推荐阅读本演示文稿。

Answer 2

HotSpot的优化与开发人员在Java源代码级别上所做的工作不同，尽管其中一些优化具有相同的净效果。

这是JIT编译器库的一部分：

• 方法调用内联；
• 将价值观从循环中提升出来；
• 单形呼叫位点；
• 将物体放置在堆栈中，以逃避分析为前提；
• 将变量绑定到CPU寄存器；
• 锁射。

最有趣的部分是一些优化之间的协同作用，例如：

1. 呼叫站点被实现为单一形式；
2. 这允许方法内联；
3. 它邀请对象的堆栈放置；
4. 它允许将对象的字段绑定到寄存器。

然而，据我所知，你的话是错误的。优化后的代码不会进行任何自剖析，因为它会减慢它的速度。去优化的唯一条件是违反乐观假设，在这种假设下，代码是JIT编译的。示例:给定的方法调用站点只接收一种类型的对象，专门处理该对象(编译为单一形式的调用站点)，但随后出现了不同的对象类型。现在，优化的代码无法执行，必须进行去优化。