3

我阅读了有关即时编译 (JIT)的信息，据我所知，有两种方法可以解决这个问题——解释器和 JIT，它们都在运行时解释字节码。

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

4

3 回答 3

6

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

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

于 2013-04-06T20:03:17.127 回答
4

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

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

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

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

于 2013-04-06T19:40:19.620 回答
0

我找到了显示运行时重新编译如何优化性能并节省额外 CPU 周期的链接。

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

这是上面给出的相同解释的另一个链接。

于 2016-09-24T21:43:40.143 回答