即时编译和堆栈替换之间的差异 [英] Differences between Just in Time compilation and On Stack Replacement

问题描述

他们几乎做同样的事情。识别该方法是热的，并编译它，而不是解释。使用OSR，你只是在编译后移动到编译版本，与JIT不同，当JIT第二次调用该方法时，编译的代码被调用。

Both of them pretty much do the same thing. Identify that the method is hot and compile it instead of interpreting. With OSR, you just move to the compiled version right after it gets compiled, unlike with JIT, where the compiled code gets called when the method is called for the second time.

除此之外，是否还有其他差异？

Other than this, are there any other differences?

推荐答案

一般来说，及时编译指的是在运行时编译本地代码并执行它而不是（或除了）解释。有些VM（例如Google V8）甚至没有翻译器;它们JIT编译每个执行的函数（具有不同程度的优化）。

In general, Just-in-time compilation refers to compiling native code at runtime and executing it instead of (or in addition to) interpreting. Some VMs, such as Google V8, don't even have an interpreter; they JIT compile every function that gets executed (with varying degrees of optimization).

堆栈替换（OSR）是一种用于在相同函数的不同实现之间切换的技术。例如，您可以在完成编译后立即使用OSR从解释或未优化的代码切换到JIT代码。

On Stack Replacement (OSR) is a technique for switching between different implementations of the same function. For example, you could use OSR to switch from interpreted or unoptimized code to JITed code as soon as it finishes compiling.

OSR在您将函数标识为热，而它正在运行。这可能不一定是因为函数被频繁调用;它可能只被调用一次，但它在大循环中花费大量时间，这可以从优化中受益。当OSR发生时，VM被暂停，并且目标函数的堆栈帧被可能在不同位置具有变量的等效帧替换。

OSR is useful in situations where you identify a function as "hot" while it is running. This might not necessarily be because the function gets called frequently; it might be called only once, but it spends a lot of time in a big loop which could benefit from optimization. When OSR occurs, the VM is paused, and the stack frame for the target function is replaced by an equivalent frame which may have variables in different locations.

OSR也可能发生在另一个方向：从优化的代码到未优化的代码或解释的代码。优化代码可以基于过去的行为对程序的运行时行为做出一些假设。例如，如果你只看过一种类型的接收器对象，你可以将虚拟或动态方法调用转换为静态调用。如果后来发现这些假设是错误的，则OSR可以用于落后于更保守的实现：优化的栈帧被转换为未优化的栈帧。如果VM支持内联，您甚至可能最终将优化的堆栈帧转换为多个未优化的堆栈帧。

OSR can also occur in the other direction: from optimized code to unoptimized code or interpreted code. Optimized code may make some assumptions about the runtime behavior of the program based on past behavior. For instance, you could convert a virtual or dynamic method call into a static call if you've only ever seen one type of receiver object. If it turns out later that these assumptions were wrong, OSR can be used to fall back to a more conservative implementation: the optimized stack frame gets converted into an unoptimized stack frame. If the VM supports inlining, you might even end up converting an optimized stack frame into several unoptimized stack frames.

这篇关于即时编译和堆栈替换之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！