关于HotSpot的动态去优化

Question

当我阅读“Scala in depth”一书时，它提到HotSpot编译器有几个重要的功能，其中之一就是“动态去优化”：

  

能够确定优化是否不，实际上是提高性能并撤消该优化，允许其他人应用

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

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

HotSpot会尝试任何常见的“优化”吗？

Answer 1

Oracle提供(rather concise) summary of this performance techniques applied by the JVM。它解释说：

  

去优化是将优化的堆栈帧更改为的过程   一个未经优化的。关于编译方法，它也是   使用无效的乐观优化抛弃代码的过程，   并用更少优化，更健壮的代码替换它。一种方法可以在   原则被重复优化了几十次。

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

  

  
1. 编译器可能会删除一个未被删除的分支，并且如果它被采用则取消优化。
  
2. 同样适用于历史上从未失败的低级别安全检查。
  
3. 如果调用网站或强制转换遇到意外类型，编译器会进行优化。
  
4. 如果加载的类使早期的类层次结构分析无效，则强制在任何线程中激活任何受影响的方法   安全点和去优化。
  
5. 这种间接去优化是由依赖系统调节的。如果编译器做出未经检查的假设，则必须注册a   可检查的依赖性。 （例如，Foo类没有子类，或者   方法Foo.bar没有覆盖。）
  

就我个人而言，我发现微基准测试的this blog entry非常易读，也涵盖了HotSpot VM上的优化和去优化主题。另外，我可以推荐reading through this presentation。

Answer 2

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

这是JIT编译器的一部分：

• 方法调用内联;
• 从循环中提升值;
• 单形呼叫站点;
• 将对象放置在堆栈上，符合Escape Analysis;
• 将变量绑定到CPU寄存器;
• 锁定elision。

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

1. 调用网站实现为单形;
2. 这允许方法内联;
3. 邀请对象的堆栈放置;
4. 允许将对象的字段绑定到寄存器。

然而，你的引言是我所知道的错误。优化的代码不会进行任何自我分析，因为它会降低它的速度。去优化的唯一条件是违反乐观假设，在这些假设下代码是JIT编译的。示例：给定的方法调用站点只接收一种类型的对象，专门用于该对象（编译为单态调用站点），但稍后会出现不同的对象类型。现在优化的代码无法执行，必须进行去优化。

Answer 3

“编译器优化”是代码的转换，试图在某种意义上使其更好 - 通常，它需要更少的时间来执行。 Wikipedia article on optimizing compilers有一个很好的常见优化列表; Hotspot JIT编译器可能会完成所有这些工作以及更多工作。

所以这本书意味着Hotspot会将一些这些技术应用到代码中，看看它是否能改善运行时，如果没有，它会还原它。

正如您所说的那样，手动更改代码以使其更好的过程也称为“优化”或“手动优化”。编译器尝试尽可能多地应用优化，但仍需要手动应用许多可能的修改。再次Wikipedia has a solid article about what a program optimization is。