java JIT 与解释器

JIT vs Interpreters

提问by Manoj

I couldn't find the difference between JIT and Interpreters.

我找不到 JIT 和解释器之间的区别。

Jit is intermediary to Interpreters and Compilers. During runtime, it converts byte code to machine code ( JVM or Actual Machine ?) For the next time, it takes from the cache and runs Am I right?

Jit 是解释器和编译器的中介。在运行时，它将字节码转换为机器码（JVM 或实际机器？）下一次，它从缓存中获取并运行我对吗？

Interpreters will directly execute bytecode without transforming it into machine code. Is that right?

解释器将直接执行字节码而不将其转换为机器码。是对的吗？

How the real processor in our pc will understand the instruction.?

我们电脑中的真正处理器将如何理解指令。？

Please clear my doubts.

请解开我的疑惑。

回答by KGhatak

First thing first:
With JVM, both interpreter and compiler(the JVM compiler and not the source-code compiler like javac) produce native code(aka Machine language code for the underlying physical CPU like x86) from byte code.

首先：
使用 JVM，解释器和编译器（JVM 编译器，而不是像 javac 这样的源代码编译器）都从字节码生成本机代码（也就是用于像 x86 这样的底层物理 CPU 的机器语言代码）。

What's the difference then:
The difference is in how they generate the native code, how optimized it is as well how costly the optimization is. Informally, an interpreter pretty much converts each byte-code instruction to corresponding native instruction by looking up a predefined JVM-instruction to machine instruction mapping (see below pic). Interestingly, a further speedup in execution can be achieved, if we take a section of byte-code and convert it into machine code - because considering a whole logical section often provides rooms for optimization as opposed to converting (interpreting) each line in isolation (to machine instruction). This very act of converting a section of byte-code into (presumably optimized) machine instruction is called compiling (in the current context). When the compilation is done at run-time, the compiler is called JIT compiler.

那么有什么区别：
区别在于它们如何生成本机代码、优化程度以及优化的成本。非正式地，解释器通过查找预定义的 JVM 指令到机器指令的映射，几乎将每个字节码指令转换为相应的本机指令（见下图）。有趣的是，如果我们采用一段字节码并将其转换为机器代码，则可以进一步加快执行速度——因为考虑整个逻辑部分通常会提供优化空间，而不是单独转换（解释）每一行（机器指令）。将一段字节码转换为（大概是优化的）机器指令的这种行为称为编译（在当前上下文中）。当编译在运行时完成时，编译器称为 JIT 编译器。

The co-relation and co-ordination:
Since Java designer went for (hardware & OS) portability, they had chosen interpreter architecture (as opposed to c style compiling, assembling, and linking). However, in order to achieve more speed up, a compiler is also optionally added to a JVM. Nonetheless, as a program goes on being interpreted (and executed in physical CPU) "hotspot"s are detected by JVM and statistics are generated. Consequently, using statistics from interpreter, those sections become candidate for compilation (optimized native code). It is in fact done on-the-fly (thus JIT compiler) and the compiled machine instructions are used subsequently (rather than being interpreted). In a natural way, JVM also caches such compiled pieces of code.

相互关系和协调：
由于 Java 设计者追求（硬件和操作系统）可移植性，因此他们选择了解释器架构（而不是 C 风格的编译、组装和链接）。但是，为了实现更高的速度，还可以选择将编译器添加到 JVM。尽管如此，当程序继续被解释（并在物理 CPU 中执行）时，JVM 会检测到“热点”并生成统计信息。因此，使用解释器的统计数据，这些部分成为编译的候选（优化的本机代码）。它实际上是即时完成的（因此是 JIT 编译器），并且随后使用编译的机器指令（而不是被解释）。自然而然地，JVM 也会缓存这些编译后的代码片段。

Words of caution:
These are pretty much the fundamental concepts. If an actual implementer of JVM, does it a bit different way, don't get surprised. So could be the case for VM's in other languages.

警告：
这些几乎是基本概念。如果 JVM 的实际实现者，它的方式有点不同，请不要感到惊讶。其他语言的 VM 可能也是这种情况。

Words of caution:
Statements like "interpreter executes byte code in virtual processor", "interpreter executes byte code directly", etc. are all correct as long as you understand that in the end there is a set of machine instructions that have to run in a physical hardware.

注意事项：
“解释器在虚拟处理器中执行字节码”、“解释器直接执行字节码”等语句都是正确的，只要你明白最终有一组机器指令必须运行一个物理硬件。

Some Good References:[I've not done extensive search though]

一些好的参考资料：[虽然我没有进行广泛的搜索]

• [paper] Instruction Folding in a Hardware-Translation Based Java Virtual Machine by Hitoshi Oi
• [book] Computer organization and design, 4th ed, D. A. Patterson. (see Fig 2.23)
• [web-article] JVM performance optimization, Part 2: Compilers, by Eva Andreasson (JavaWorld)

• [论文] Hitoshi Oi 在基于硬件翻译的 Java 虚拟机中的指令折叠
• [书] 计算机组织与设计，第 4 版，DA Patterson。（见图 2.23）
• [网络文章] JVM 性能优化，第 2 部分：编译器，作者：Eva Andreasson (JavaWorld)

PS: I've used following terms interchangebly - 'native code', 'machine language code', 'machine instructions', etc.

PS：我交替使用了以下术语——“本机代码”、“机器语言代码”、“机器指令”等。

回答by gpeche

• Interpreter: Reads your source code or some intermediate representation (bytecode) of it, and executes it directly.

• JIT compiler: Reads your source code, or more typically some intermediate representation (bytecode) of it, compiles that on the fly and executes native code.

• 解释器：读取您的源代码或它的一些中间表示（字节码），并直接执行它。

• JIT 编译器：读取您的源代码，或者更典型的是它的一些中间表示（字节码），即时编译并执行本机代码。

回答by Vivien Barousse

Jit is intermediary to Interpreters and Compilers. During runtime, it converts byte code to machine code ( JVM or Actual Machine ?) For the next time, it takes from the cache and runs Am i right?

Jit 是解释器和编译器的中介。在运行时，它将字节码转换为机器码（JVM 或实际机器？）下一次，它从缓存中获取并运行我对吗？

Yes you are.

是的，你是。

Interpreters will directly execute bytecode without transforming it into machine code. Is that right?

解释器将直接执行字节码而不将其转换为机器码。是对的吗？

Yes, it is.

是的。

How the real processor in our pc will understand the instruction.?

我们电脑中的真正处理器将如何理解指令。？

In the case of interpreters, the virtual machine executes a native JVM procedure corresponding to each instruction in byte code to produce the expected behaviour. But your code isn't actually compiled to native code, as with Jit compilers. The JVM emulates the expected behaviour for each instruction.

在解释器的情况下，虚拟机执行与字节码中的每条指令相对应的本地 JVM 过程，以产生预期的行为。但是您的代码实际上并未像 Jit 编译器那样编译为本机代码。JVM 模拟每条指令的预期行为。

回答by Jér?me Radix

A JIT Compilertranslates byte code into machine code and then execute the machine code.

甲JIT编译器翻译的字节码转换成机器代码，然后执行该机器代码。

Interpretersread your high level language (interprets it) and execute what's asked by your program. Interpreters are normally not passing through byte-code and jit compilation.

口译员阅读您的高级语言（解释它）并执行您的程序要求的内容。解释器通常不通过字节码和 jit 编译。

But the two worlds have melt because numerous interpreters have take the path to internal byte-compilation and jit-compilation, for a better speed of execution.

但是这两个世界已经融化了，因为许多解释器已经采取了内部字节编译和 jit 编译的路径，以提高执行速度。

回答by Aaron

I'm pretty sure that JIT turns byte code into machine code for whatever machine you're running on right as it's needed. The alternative to this is to run the byte code in a java virtual machine. I'm not sure if this the same as interpreting the code since I'm more familiar with that term being used to describe the execution of a scripting (non-compiled) language like ruby or perl.

我很确定 JIT 会根据需要将字节码转换为机器码，用于您正在运行的任何机器。对此的替代方法是在 Java 虚拟机中运行字节码。我不确定这是否与解释代码相同，因为我更熟悉用于描述脚本（非编译）语言（如 ruby​​ 或 perl）的执行的术语。

回答by bitan

The first time a class is referenced in JVM the JIT Execution Engine re-compiles the .class files (primary Binaries) generated by Java Compiler containing JVM Instruction Set to Binaries containing HOST system's Instruction Set. JIT stores and reuses those recompiled binaries from Memory going forward, there by reducing interpretation time and benefits from Native code execution.

第一次在 JVM 中引用类时，JIT 执行引擎会将包含 JVM 指令集的 Java 编译器生成的 .class 文件（主要二进制文件）重新编译为包含 HOST 系统指令集的二进制文件。JIT 存储和重用那些从内存中重新编译的二进制文件，从而减少解释时间并从本地代码执行中受益。

And there is another flavor which does Adaptive Optimization by identifying most reused part of the app and applying JIT only over it, there by optimizing over memory usage.

还有另一种方法是通过识别应用程序中最重用的部分并仅对其应用 JIT 来进行自适应优化，从而优化内存使用。

On the other hand a plain old java interpreter interprets one JVM instruction from class file at a time and calls a procedure against it.

另一方面，一个普通的旧 Java 解释器一次从类文件中解释一个 JVM 指令，并针对它调用一个过程。

Find a detail comparison here

在此处查找详细比较