与传统编译器相比，JIT 编译器有什么缺点吗？
可能的重复：
JIT 编译器与离线编译器
所以直到几分钟前我才真正明白什么JIT 编译器和解释器之间的区别是。浏览SO，我找到了答案，它提出了标题中的问题。据我发现，JIT 编译器的优点是能够使用其运行的特定处理器，从而可以生成更好的优化程序。有人可以给我比较一下各自的优缺点吗？
Possible Duplicate:
JIT compiler vs offline compilers
So until a few minutes ago I didn't really understand what the difference between a JIT compiler and an interpreter is. Browsing through SO, I found the answer, which brought up the question in the title. As far as I've found, JIT compilers have the benefit of being able to use the specific processor it's running on and can thus make better optimized programs. Could somebody please give me a comparison of the pros and cons of each?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
解释器、JIT 编译器和“离线”编译器
为了简单起见，我们假设解释器将运行字节码（中间代码/语言）。当虚拟机/解释器决定这样做更好时，JIT 编译机制会将相同的字节码转换为针对相关硬件的本地代码，重点关注所请求的优化类型。
我认为您缺少的是 JIT 编译发生在运行时，而不是编译时（与“离线”编译器不同）
JIT 编译有开销
编译代码是不是免费的，也需要时间。如果它投入时间进行编译，然后只运行几次，那么它可能不会做出一笔好的交易。因此，虚拟机仍然必须决定将什么定义为“热点”并对其进行 JIT 编译。
请允许我给出有关 Java 虚拟机 (JVM) 的示例：
JVM 可以使用开关，您可以使用这些开关定义阈值，在该阈值之后代码将被 JIT 编译。
-XX:CompileThreshold=10000为了说明 JIT 编译时间的成本，假设您将该阈值设置为 20，并且有一段代码需要运行 21 次。发生的情况是，在运行 20 次之后，VM 现在将投入一些时间对其进行 JIT 编译。现在，您拥有了来自 JIT 编译的本机代码，但它只会再运行一次（21 次），这可能不会带来任何性能提升来弥补 JIT 过程。
我希望这能说明这一点。
这是一个 JVM 开关，显示 JIT 编译所花费的时间
-XX:-CITime“打印 JIT 编译器所花费的时间”旁注：我不认为这是一个“有什么大不了的”，自从你提出这个问题以来我就想指出这一点。
Interpreter, JIT Compiler and "Offline" Compiler
To keep it simple, let's just say that an interpreter will run the bytecode (intermediate code/language). When the VM/interpreter decides it is better to do so, the JIT compilation mechanism will translate that same bytecode into native code targetted for the hardware in question, with focus on the type of optimizations requested.
I think what you are missing is that the JIT compilation happens at runtime and not compile time (unlike an "offline" compiler)
JIT Compilation has overhead
Compiling code is not free, takes time also. If it invests time on compiling it and then goes to run it only a few times, it might not have made a good trade. So the VM still has to decide what to define as a "hot spot" and JIT-compile it.
Allow me to give examples on the Java virtual machine (JVM):
The JVM can take switches with which you can define the threshold after which the code will be JIT compiled.
-XX:CompileThreshold=10000To illustrate the cost of the JIT compilation time, suppose you set that threshold to 20, and have a piece of code that needs to run 21 times. What happens is after it runs 20 times, the VM will now invest some time into JIT compiling it. Now you have native code from the JIT compilation, but it will only run for one more time (the 21), which may not have brought any performance boost to make up for the JIT process.
I hope this illustrates it.
Here is a JVM switch that shows the time spent on JIT compilation
-XX:-CITime"Prints time spent in JIT Compiler"Side Note: I don't think it's a "big deal", just something I wanted to point out since you brought up the question.
JIT 编译本质上并不意味着它很容易反汇编。这更依赖于实现，例如 Java 二进制文件。但请注意，JIT 可以应用于任何类型的可执行文件，无论是 Java、Python，甚至是 C++ 或类似文件中已编译的二进制文件。 （IIRC，Dynamo 项目涉及动态重新编译此类二进制文件以提高性能。）
JIT 编译的权衡是，虽然该过程的目标是提高运行时性能，但该过程实际上也在运行时发生，因此，在分析、编译和验证代码片段时会产生开销。如果实现效率低下或者没有进行足够的优化，那么它实际上会导致性能下降。
另一个权衡是，在某些情况下，JIT 编译可能非常浪费。例如，考虑一个自修改的可执行文件。如果编译代码片段，然后可执行文件修改该片段，则必须丢弃已编译的片段，然后重新分析该片段以确定是否值得重新编译。如果这种情况频繁发生，则会严重影响性能。
最后，内存消耗也会受到影响，因为编译后的代码片段必须驻留在内存中才能有效。这对于内存有限的设备来说是不切实际的，或者很难很好地实现。
JIT compilation doesn't inherently mean it is easy to disassemble. That is more implementation-dependent, such as with Java binaries. Note, however, that JIT can be applied to any kind of executable, whether it is Java, Python or even an already-compiled binary from C++ or similar. (IIRC, the Dynamo project involved re-compiling such binaries on-the-fly to increase performance.)
The trade-off for JIT compilation is that while the process's goal is to increase runtime performance, the process actually occurs at runtime as well, and so it incurs overhead while analyzing, compiling, and validating code fragments. If the implementation is inefficient or not enough optimizations occur, then it actually produces a performance degradation.
The other trade-off is that in some cases the JIT compilation can be very wasteful. For example, consider a self-modifying executable. If you compile a fragment of code, and then the executable modifies that fragment, you have to throw away the compiled fragment and then re-analyze that segment to determine if it is worth re-compiling. If this happens frequently, there is a significant performance hit.
Finally, there is a hit in memory consumption, as compiled code fragments must reside in memory in order to be effective. This can make it impractical for devices with limited amounts of memory, or else extremely difficult to implement well.
至少对我来说，缺乏内联 ASM 是一个很大的问题。有时，您只想完全控制程序的一小部分的 CPU 每个细节。即使我不需要它来完成手头的任务，我也喜欢这样的想法：原则上我的计算机能够完成的所有事情都可以用我的语言完成。
For me, at least, lack of inline ASM is a big one. Once in a while, you just want complete control over every detail of the CPU for some small part of your program. Even when I don't need it for the task at hand, I like the idea that everything that my computer is capable of can, in principle be done within my language.
JIT 编译器具有更多的内存开销，因为除了 AOT（提前）编译程序所需的运行时库和编译代码之外，它们还需要加载编译器和解释器。
JIT compilers have a lot more memory overhead since they need to load a compiler and interpreter in addition to the runtime libraries and compiled code that an AOT (ahead-of-time) compiled program requires.
JIT 编译器更难编写（不是全部，但值得一提）。
JIT compilers are harder to write (not the whole story, but worth mentioning).
我想说，使用 JIT 编译器的一个真正缺点（实际上更多的是副作用）是，是否可以轻松地将 IL 分解为人类可读的代码。
I would say one real disadvantage of using a JIT compiler (more of a side effect really), is that is it easy to dissassemble the IL into human readable code.