为什么 Java 的 JIT 编译器不将所有内容转换为本机代码?

发布于 2024-11-30 03:59:32 字数 90 浏览 3 评论 0原文

我一直在研究 Java JIT 编译器,但我无法弄清楚为什么某些代码仍然被解释。为什么 JIT 编译器不将所有内容都翻译为本机代码?翻译速度慢了很多,我错过了什么吗?

I have been looking into the Java JIT compiler and i cannot figure out why some of the code is still interpreted. Why doesn't the JIT compiler translate everything to native code? Interpretation is much slower, am I missing something?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

旧人九事 2024-12-07 03:59:32

这都是一个权衡的问题,

  • 编译+执行代码所花费的时间可能比解释的时间更长,一旦
  • 你经常可以更有效地优化东西,如果你有分支的统计数据,等等,
  • 有些东西不能被编译(任何不能编译的东西) RTTI,可能)
  • 一些你不想编译的东西(堆栈跟踪的行号等)
  • 我确信还有其他东西。

It's all a matter of tradeoffs

  • the time taken to compile + execute code can be longer than the time to interpret once
  • you can often optimise things much more efficiently if you have statistics on branching, etc
  • some things can't be compiled (anything that does RTTI, probably)
  • some things you don't want compiled (line numbers for stack traces, etc)
  • I'm sure there's others.
桃酥萝莉 2024-12-07 03:59:32

如果您正在运行像 HotSpot 这样的 JVM,它会适时进行 JIT 编译,只关注频繁执行的代码。它通过计算每个代码块(或方法 - 我不确定是哪个)的频率来确定要动态优化的代码。因此,在启动时,一切都会被解释。

其背后的目的是通过只需要优化一小部分代码来允许更积极和更昂贵的优化。

If you are running a JVM like HotSpot, it JIT-compiles opportunistically, only focusing on code that executes frequently. It determines which code to optimise on the fly by counting frequency of each code block (or method — I'm not sure which). Consequently, at startup time, everything is interpreted.

The intent behind this is allow for much more aggressive and expensive optimisations by only requiring a small fraction of the code to be optimised.

被翻牌 2024-12-07 03:59:32

两个主要原因:

  • 如果代码只运行几次,解释速度并不会变慢。如果代码只运行几次,那么单独编译的成本可能比解释代码要昂贵得多。
  • 在解释时,可以在运行时收集统计信息,这对于以后优化代码很有用。例如,您可以计算特定分支被采用的次数,并优化代码,使其在更频繁的情况下速度更快。这种技巧可以使 JIT 编译比提前编译(没有机会利用运行时统计信息)更好,

因此 Java JIT 采取了一个明智的策略:在观察到相同的代码之前不要编译被运行多次,此时您有证据表明进行编译可能是值得的,并且您可以进行一些额外的优化。

Two main reasons:

  • Interpretation is not slower if code is only run a few times. The cost of compilation alone can be much more expensive than interpreting the code if it is only run a few times.
  • While interpreting it is possible to gather statistics at runtime that are useful for optimising the code later. For example, you can count how many times a particular branch is taken and optimise the code to be faster for the more frequent case. This kind of trick can make JIT compilation better than ahead-of-time compilation (which doesn't have the opportunity to exploit the runtime statistics)

Hence the Java JIT takes a sensible strategy: don't compile until you observe that the same code is being run multiple times, at which point you have evidence that doing the compilation is probably worthwhile and you are able to make some additional optimisations.

意中人 2024-12-07 03:59:32

JIT 编译器使用程序执行统计信息动态优化代码。例如,“热路径”优化对程序某一部分的命中次数进行计数,并仅针对程序中频繁执行的那些部分生成机器代码。这允许 JIT 优化器将频繁执行的机器代码片段放置在一起,以便它们适合处理器的缓存。这使得 JIT 编译器的性能优于预编译的机器代码。

JIT compiler optimizes code on the fly using program execution statistics. For example, "hotpath" optimization counts the number of hits in one part of the program and generates machine code only for those parts of the code where the program is executed frequently. This allows the JIT optimizer to place pieces of frequently executed machine code close together so that they fit into the processor's cache. This allows the JIT compiler to outperform precompiled machine code.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文