.NET CLR JIT 是否每次都编译每个方法？答案

【问题标题】：Does the .NET CLR JIT compile every method, every time?.NET CLR JIT 是否每次都编译每个方法？
【发布时间】：2010-11-18 08:30:03
【问题描述】：

我知道，如果 Java 的 HotSpot JIT 期望编译的开销低于在解释模式下运行方法的开销，它有时会跳过 JIT 编译方法。 .NET CLR 是否基于类似的启发式工作？

【问题讨论】：

标签： .net clr jit

【解决方案1】：

注意：此答案基于“每次运行”上下文。每次运行程序时，通常都会对代码进行 JIT 处理。使用 ngen 或 .NET Native 也会改变这个故事......

与 HotSpot 不同，CLR JIT 每次运行总是精确编译一次。它从不解释，也从不根据实际使用情况进行比以前更重的优化重新编译。

当然，这可能会改变，但从 v1 开始就是这样，我预计不会很快改变。

优点是它使 JIT 更简单 - 无需考虑已经运行的“旧”代码、基于不再有效的前提撤消优化等。

.NET 的优势之一是大多数 CLR 语言默认将方法设为非虚拟，这意味着可以进行更多的内联。 HotSpot 可以内联一个方法，直到它第一次被覆盖，此时它撤消优化（或者在某些情况下做一些聪明的事情以根据实际类型有条件地仍然使用内联代码）。由于需要担心的虚拟方法更少，.NET 可以在很大程度上忽略无法内联任何虚拟的痛苦。

编辑：上面描述了桌面框架。 Compact Framework 会在需要时抛出本地代码，并在必要时再次 JIT。但是，这仍然不像 HotSpots 自适应优化。

微框架显然根本不 JIT，而是解释代码。这对于非常受限的设备是有意义的。（我不能说我对微框架了解多少。）

【讨论】：

我明白了......所以 .Net CLR 在解释模式下运行的唯一时间是 JIT 完全关闭（用于调试）。
我不相信它实际上解释了代码——调试器能够适当地单步调试编译的代码，仅此而已。 Mono 确实有一个解释器。
奇怪的是，.net MF（嵌入式设备的微框架）确实解释了 IL 而不是编译它。
桌面 CLR 不会投放（卸载）jitted 代码，因此它只编译一个方法一次。 .NET Compact Framework 中的 CLR 可以调整代码并在再次需要时重新调整代码，以适应紧凑型 CLR 运行的资源更受限的环境。
糟糕——是的，当我有机会时，我会编辑我过于笼统的答案。感谢您的更正。

【解决方案2】：

.NET 运行时总是在执行前编译代码 JIT。所以，它永远不会被解释。

您可以在 CLR Design Choices 和Anders Hejlsberg 中找到一些更有趣的读物。特别是部分：

我读到微软决定 IL 将始终被编译，从不解释。指令中的编码类型信息如何帮助解释器更高效地运行？

Anders Hejlsberg：如果解释器可以盲目地按照指令所说的去做，而不需要跟踪堆栈顶部的内容，那么它可以运行得更快。例如，当它看到一个 iadd 时，解释器不必首先弄清楚它是哪种类型的 add，它知道它是一个整数 add。假设有人已经验证了堆栈看起来是正确的，那么可以安全地减少一些时间，并且您关心的是解释器。但是，在我们的例子中，我们从未打算使用 CLR 来定位解释的场景。我们打算始终 JIT [即时编译]，并且出于 JIT 的目的，无论如何我们都需要跟踪类型信息。因为我们已经有了类型信息，所以它实际上并没有给我们买任何东西来把它放在说明中。

Bill Venners：许多现代 JVM [Java 虚拟机] 进行自适应优化，从解释字节码开始。他们在应用程序运行时对其进行分析，以找到在 80% 到 90% 的时间内执行的 10% 到 20% 的代码，然后将其编译为本机。不过，它们不一定及时编译这些字节码。方法的字节码仍然可以由解释器执行，因为它们正在被编译为本机并在后台进行优化。当本机代码准备好时，它可以替换字节码。通过不针对解释的场景，您是否完全排除了在 CLR 中执行的方法？

Anders Hejlsberg：不，我们还没有完全排除这种可能性。我们仍然可以解释。我们只是没有针对口译进行优化。我们没有针对编写只会解释的最高性能解释器进行优化。我认为没有人会再这样做了。对于 10 年前的机顶盒来说，这可能很有趣。但这不再有趣了。 JIT 技术已经发展到可以拥有多种可能的 JIT 策略的地步。你甚至可以想象使用一个快速运行的快速 JIT，然后当我们发现我们一直在执行一个特定的方法时，使用另一个花费更多时间并且在优化方面做得更好的 JIT。您可以在 JIT 方面做更多的事情。

【讨论】：

【解决方案3】：

将来很高兴看到一些基于跟踪的 JIT 用于内存不足的设备。它主要会解释，找到热点，并将它们转换为汇编程序并缓存它们。我认为这就是 Google 使用他们的 Android JIT 所做的事情，Microsoft Research 正在进行一个基于跟踪的 JIT 的研究项目。

我发现了一篇文章，SPUR: A Trace-Based JIT Compiler for CIL.. 也许其中一些内容有一天会成为CLR？

【讨论】：

【解决方案4】：

我不这么认为，我也不认为它应该如此。

JIT 怎么知道特定方法会被调用多少次？解释的频率不会影响决策吗？

我还会质疑 JIT 编译器在不解释函数本身的情况下分析函数以确定解释是否最好的能力。考虑到这一事实（该方法至少已通过一次），是否最好简单地编译每个方法以减少尝试确定首先编译哪些方法的开销？

【讨论】：

@Andrew - 运行时性能指标可以告诉您是否应该对某些东西进行 jit，以及应该对它进行多大程度的 jit（b/c 一些 JIT 优化比其他优化更耗时）。
只是一个想法（我怀疑 HotSpot 是否像这样工作） - 您可以静态分析一些东西（如方法的长度）（在生成字节码时）并做出决定，然后，只需将此方法标记为“不编译”位，因此 JIT 会知道它不应该编译它，而是在需要时回退到解释器。
java.sun.com/products/hotspot/whitepaper.html - HotSpot 可以就地替换代码，即使代码正在堆栈上执行。因此，循环可以在解释模式下开始，但在重新编译完成后在 JIT 编译模式下结束。