.NET 运行时与 Java 热点：.NET 落后一代了吗？

Question

根据我收集到的关于.NET和Java执行环境的信息，目前的情况如下：

• 现代 Java VM 能够执行连续重新编译，结合分析可以产生巨大的性能改进。较旧的 JVM 采用 JIT。 本文中的更多信息： http://www.ibm.com/developerworks/library/j-jtp12214/ 尤其是：Java theory and practice: Dynamic compilation and performance measurement

• .NET 使用 JIT 或 NGEN 来生成本机代码，但是一旦生成本机代码，就不会执行进一步的（运行时）优化。

抛开基准测试并无意升级圣战，这是否意味着 Java Hotspot VM 比 .Net 领先一代。 Java VM 中采用的这些技术最终会进入 .NET 运行时吗？

Answer 1

他们遵循两种不同的策略。我不认为一个比另一个更好。

• .NET 不解释字节码，因此它必须按原样 JIT 执行所有内容，因此由于时间限制无法进行大量优化。如果您需要对代码的某些部分进行大量优化，您始终可以手动对其进行 NGEN，或者进行快速但 unsafe 的实现。此外，calling native code is easy。 这里的方法似乎是让运行时足够好并手动优化瓶颈。

• 现代 JVM 通常会解释大部分代码，然后对瓶颈进行优化编译。这通常比直接 JIT 获得更好的结果，但如果您需要更多，Java 中没有 unsafe 和 calling native code is not nice。 所以这里的方法是尽可能多地进行自动优化，因为其他选项不是那么好。

实际上，与 .NET 相比，Java 应用程序在时间上的性能往往稍好一些，而在空间上的性能则较差。

Answer 2

我从未对两者进行基准比较，而且我对 Sun JVM 更熟悉，我只能笼统地谈论 JIT。

优化总是需要权衡取舍，并非所有优化都始终有效。但是，这里有一些现代 JIT 技术。如果我们坚持技术方面的内容，我认为这可能是一次良好对话的开始：

• 逃逸分析
• intrinsics
  • http://bugs.sun.com/view_bug.do?bug_id=6823354
  • http://weblog.ikvm.net/CommentView.aspx?guid=0404dd8a-88a8-4d62-9bcb-98324d57a2a9
• tail-call optimization
• 堆栈替换
• 锁粗化
• lock elision
• 多线程垃圾回收
• 低暂停垃圾回收
• polymorphic method call removal
• fast heap allocation

就良好的 VM go 实现而言，还有一些有用的功能：

• 能够在 GC 之间进行选择
• 每个 GC 的实现自定义
• 堆分配参数（例如增长）
• 页面锁定

基于这些特性以及更多特性，我们可以比较虚拟机，而不仅仅是“Java”与“.NET”，还有 Sun 的 JVM 与 IBM 的 JVM 与 .NET 与 Mono。

例如，Sun 的 JVM 不做尾部调用优化，IIRC，但 IBM 做。

Answer 3

显然有人正在为Rotor 做类似的事情。我无权访问 IEEE，因此无法阅读摘要。

Dynamic recompilation and profile-guided optimisations for a .NET JIT compiler

摘自摘要...

使用 a 评估框架 一组测试程序表明 性能可以提高最大 42.3%，平均下降 9%。 我们的 结果还表明，间接费用 收集准确的个人资料 通过仪器信息 一定程度上大于好处 在我们的配置文件引导优化 实施，表明需要 用于实施技术，可以 减少此类开销。

Answer 4

您可能对SPUR 感兴趣，它是一个跟踪 JIT 编译器。重点是 javascript，但它在 CIL 上运行，而不是语言本身。这是一个基于 Bartok 而非标准 .NET VM 的研究项目。该论文有一些性能基准，显示'它始终比标准 3.5 CLR 的 SPUR-CLR' 执行得更快。然而，没有任何关于它与当前 VM 相关的未来的公告。跟踪可以跨越方法边界，这不是 HotSpot AFAIK 所做的事情，提到了 JVM 跟踪 JIT here。

我会犹豫说 .NET VM 落后了一代，尤其是在考虑所有子系统时，尤其是泛型。 GC 和 DLR 与 invokedynamic 的比较我不确定，但在像 channel9 这样的地方有很多关于它们的细节。