JVM中的JIT编译器究竟是什么？

Question

我正在尝试理解Java源代码是如何执行的，而我对JVM内部的JIT编译器实际上是什么感到困惑。首先，让我告诉您我是如何理解从Java源代码到在计算机上执行机器代码的过程。也许，我误解了导致混乱的过程中的某些事情。

步骤：

1. 源代码被编译为字节码（.class文件）
2. 类文件被加载到JVM（在RAM中）
3. 字节码经过验证，然后由JIT编译器处理
4. JIT编译器的输出是准备好执行的机器代码

现在，根据Wikipedia article on JVM，更具体地说是“字节码解释器和即时编译器”部分，为了执行Java字节码，您需要一个解释器（但是我们有一个JIT 编译器）。

现在这里有点困惑我。我把它分成了引号：

“当解释器执行Java字节码时，执行总是比编译为本机机器语言的同一程序的执行慢。”

1. 由于计算机只能执行机器代码，并且解释器在将字节码转换为机器代码方面比编译器慢，为什么JVM使用解释器而不是编译器？

2. 为什么我们没有为JIT编译器为CPU生成另一个中间可执行文件，以便它可以快速执行指令？

“JIT编译器可以在执行程序时将Java字节码转换为本机机器语言。然后，程序的翻译部分可以比它们解释的更快地执行。这种技术适用于那些部分。经常执行的程序。“

JIT编译器真的是一个能够编译频繁执行的代码的解释器吗？编译器和解释器这两个术语是否可以互换使用？

提前致谢。

Answer 1

  

由于计算机只能执行机器代码，并且解释器在将字节码转换为机器代码方面比编译器慢，为什么JVM使用解释器而不是编译器？

因为编译到机器代码也需要时间，特别是当它必须分析代码以优化它时，所以解释很快就足以执行大部分时间，并且实际上比编译+运行更快，如果只运行一次/一次。

此外，解释器不会“将字节码转换为机器代码”。它评估字节码并执行字节码所请求的操作。解释器本身是机器代码，但它不转换字节码，它解释/评估字节码。

  

为什么我们没有为JIT编译器为CPU生成另一个中间可执行文件，以便它可以快速执行指令？

这将违反Write Once，Run Anywhere范式的Java。

  

JIT编译器真的是一个能够编译经常执行的代码的解释器吗？

不，JIT编译器（或更准确地说，HotSpot编译器，如mentioned by EJP）是JVM根据需要执行的编译器。

  

编译器和解释器这两个术语是否可以互换使用？

正确。它们不能互换使用，因为它们不会做同样的事情。解释器执行字节码。 JIT / HotSpot编译器将字节码转换为机器码，但不运行它。

Answer 2

  

由于计算机只能执行机器代码和解释器   将字节码转换为机器码比编译器慢   是，为什么JVM使用解释器而不是编译器？

优化编译是一个非常持久的过程。如果程序运行时间较长，这笔费用是合理的。

在错误的地方进行优化是不必要的。一段遍历一次的代码将比解释时间消耗更多的编译时间，因此解释是可以的。

如果频繁处理代码的某些部分，编译器会更好地处理这两个主题。

  

为什么我们没有生成另一个中间可执行文件   CPU的JIT编译器，因此它可以快速执行   指令？

此“文件”（已编译的片段）确实存在于内存中。它未被序列化为文件，因为：

• 这样的文件将严重依赖于操作系统和硬件
• 某些代码优化只能在运行时应用，例如JIT编译器可以优化虚拟调用（通过跳转或甚至内联代码替换动态调度）

  

JIT编译器真的是一个能够编译＆gt;的解释器吗？经常执行的代码？是编译器和解释器这两个术语   错误地互换使用？

虽然JVM Hotspot编译器编译频繁执行的代码，但其他JIT编译器可能会根据其他启发式方法决定编译。术语“JIT编译器”和“解释器”不能清楚地区分。大多数解释器都会优化（及时编译），几乎每个JIT编译器都会解释。