即时编译和堆栈替换之间的区别
他们几乎都做同样的事情.确定该方法是热的并编译它而不是解释.使用 OSR，您只需在编译后立即转到已编译的版本，这与 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?
推荐答案
一般来说，Just-in-time编译是指在运行时编译原生代码并执行它而不是(或除了) 口译.一些虚拟机，比如 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.
相关文章