根据我在 .NET 和 Java 执行环境上收集到的信息，目前的情况如下：
现代 Java VM 能够执行连续重新编译，结合分析可以产生巨大的性能改进。较旧的 JVM 采用 JIT。本文中的更多信息：http: //www.ibm.com/developerworks/library/j-jtp12214/ 尤其是：Java 理论与实践：动态编译和性能测量
.NET 使用 JIT 或 NGEN 生成本机代码，但是一旦生成本机代码，就不会执行进一步的（运行时）优化。
抛开基准测试并无意升级圣战，这是否意味着 Java Hotspot VM 比 .Net 领先一代。Java VM 中采用的这些技术最终会进入 .NET 运行时吗？
他们遵循两种不同的策略。我不认为一个比另一个更好。
.NET 不解释字节码，因此它必须按原样 JIT 执行所有内容，因此由于时间限制无法进行大量优化。如果您需要对代码的某些部分进行大量优化，您始终可以手动对其进行 NGEN，或者进行快速但不安全的实现。此外，调用本机代码很容易。这里的方法似乎是让运行时足够好并手动优化瓶颈。
现代 JVM 通常会解释大部分代码，然后对瓶颈进行优化编译。这通常比直接 JIT 得到更好的结果，但是如果你需要更多，你unsafe在 Java 中没有，调用本机代码也不好。所以这里的方法是尽可能多地进行自动优化，因为其他选项不是那么好。
实际上，与 .NET 相比，Java 应用程序在时间上的性能往往稍好一些，而在空间上的性能则较差。
显然有人正在为Rotor做类似的事情。我无权访问 IEEE，因此无法阅读摘要。
引用摘要...
使用一组测试程序对该框架的评估表明，性能最多可以提高 42.3%，平均提高 9%。我们的结果还表明，通过检测收集准确的配置文件信息的开销在一定程度上超过了我们实现中配置文件引导优化的好处，这表明需要实现可以减少此类开销的技术。
我从来没有对两者进行基准比较，而且我对 Sun JVM 更熟悉，我只能笼统地谈论 JIT。
优化总是需要权衡取舍，并非所有优化都始终有效。但是，这里有一些现代 JIT 技术。我认为，如果我们坚持技术方面的内容，这可能是一次良好对话的开始：
就良好的 VM 实现而言，还有一些有用的功能：
基于这些特性以及更多特性，我们可以比较虚拟机，而不仅仅是“Java”与“.NET”，还有 Sun 的 JVM 与 IBM 的 JVM 与 .NET 与 Mono。
例如，Sun 的 JVM 不做尾部调用优化，IIRC，但 IBM 做。
您可能对跟踪 JIT 编译器的SPUR感兴趣。重点是 javascript，但它在 CIL 上运行，而不是语言本身。这是一个基于 Bartok 而非标准 .NET VM 的研究项目。该论文有一些性能基准显示“它始终比标准 3.5 CLR 的 SPUR-CLR 执行得更快”。但是，没有任何关于它与当前 VM 相关的未来的公告。跟踪可以跨越方法边界，这不是 HotSpot AFAIK 所做的，这里提到了 JVM 跟踪 JIT 。
我会犹豫说 .NET VM 落后了一代，尤其是在考虑所有子系统时，尤其是泛型。GC和DLR与 invokedynamic的比较我不确定，但在channel9等地方有很多关于它们的细节。