为什么不是所有的 java 字节码最初都被解释为机器码？答案

【问题标题】：Why isn't all the java bytecode initially interpreted to machine code?为什么不是所有的 java 字节码最初都被解释为机器码？
【发布时间】：2013-03-29 02:55:24
【问题描述】：

我读到了Just-in-time compilation (JIT)，据我所知，有两种方法可以解决这个问题——Interpreter 和 JIT，这两种方法都在运行时解释 bytecode。

为什么不直接将所有字节码解释为机器码，然后才开始运行进程而不再需要解释器？

【问题讨论】：

标签： jvm interpreter java bytecode

【解决方案1】：

简单：因为将所有内容预编译为机器码需要时间。并且用户不想等待应用程序启动。请记住，预编译必须进行大量优化，这需要时间。

服务器版本的 JVM 在预先编译和优化代码方面更加积极，因为服务器端的代码往往在进程关闭之前执行得更频繁、执行时间更长。

但是，一个解决方案（用于 .Net）是一个名为 NGen 的应用程序，它预先进行预编译，这样之后就不需要它了。您只需运行一次。

并非所有 VM 都包含解释器。例如 Chrome 和 CLR (.Net) 在运行之前总是编译成机器码。但是，它们具有多个级别的优化以减少启动时间。

【讨论】：

【解决方案2】：

延迟 JIT 编译的另一个原因与优化有关：在运行时，与编译器在编译时相比，VM 可以检测到它可能优化的更多/其他模式。启动时的 JIT 预编译总是必须是静态的，并且编译器已经完成了相同的工作，但是通过分析实际运行时行为，VM 可能会获得更多信息优化，因此可能会产生更好的优化结果。

例如，VM 可以检测到单个代码实际上在运行时运行了一百万次，并执行编译器可能没有相关信息的适当优化，这与现代运行时执行的分支预测不同CPU。
更多信息可以在"Adaptive optimization" 上的维基百科文章中找到。

【讨论】：

此外，它可以对行为做出假设，然后在以后违反这些假设时动态重新编译。这很重要，否则您无法真正内联虚函数。
+1，但我们在编译器中也有配置文件引导的优化，所以同样的事情（ish）可以在编译时完成。
“没有什么能比得上真实的东西。” ;) - 但是配置文件引导的优化朝着相同的方向发展。供参考：en.wikipedia.org/wiki/Profile-guided_optimization

【解决方案3】：

我发现 link 展示了运行时重新编译如何优化性能并节省额外的 CPU 周期。

内联扩展：降低过程调用的成本。
删除冗余负载：当 2 个编译代码导致某些重复代码时，可以通过在运行时重新编译将其删除并进一步优化。
复制传播
消除死代码

这里是另一个link，与上面给出的解释相同。

【讨论】：