IKVM 编程武林之.NET派的北冥神功

其实一个纠结了的...

问题是java语言的最强大之处并不在于语言啊，是JVM强大啊。

再举一些其他例子，例如反射和对象回收的频繁使用，是要基于JVM的进步才行的，如果跑在老版本的JVM上（例如没有HotSpot的JRE 1.2），还大量使用反射、大量新建临时对象，性能会极差的。

这里抽取的正好是JVM，JVM已经被换成了CLR，这是IL的映射，至于HotSpot，反正CLR都JIT了，HotSpot反而没什么必要。

HotSpot很早就开始有JIT，意思是HotSpot绝不仅仅是JIT。
这里并不是讨论HotSpot一定比CLR优秀，而是说，有不少现成的Java库的实现尤其是JDK，是根据JVM的特点优化和改进，甚至于放弃有些无用的优化，但是一旦移植到其他虚拟机平台，原本一些不是性能问题的问题，就可能爆发出来。

举个例子，JRuby也是经过不断努力，适应和充分利用JVM之后，才使得性能超过ruby原本的vm的。

观看高手们的较量

1. hotspot是种热的JIT，但是对于CLR来说，它有两种JIT,“冷”的JIT和"热"的JIT.

所谓"冷"的JIT, 即通过NGEN.exe将IL直接翻译成Native并放在GAC里，譬如java.commons这些lib，我可以全部ngen之后放入GAC里，这样hotspot反而显得更慢。在CLR 4.0中，NGEN有了很大的改进：
http://blogs.msdn.com/clrcodegeneration/archive/2009/05/03/Improvements-to-NGen-in-.NET-Framework-4.aspx

所谓"热"的JIT,即第一次调用方法的存根的时候，将方法JIT.


PS:java库根据JVM的特点优化，我愿闻其详，但就大部分java库而言，通过IKVM转换IL，并未有太多问题。

HotSpot倒不是“很早就有JIT”，而是从开始叫HotSpot的时候就已经有JIT了。因为原本没JIT的时候都还不是HotSpot……
Sun的JVM是经过了
纯解释器
=>（收购了Animorphic）
=>分离的解释器/JIT编译器（嗯还有购买了Symantec JIT的许可证）
=>演化出HotSpot，整合的解释器/优化JIT编译器

话说ice大大跟ray大大所说的东西也不矛盾……IKVM.NET确实是直接让CLI达到尽量兼容（抽象的）JVM的效果；HotSpot也确实是很强悍的JVM；其实这两个观点有啥联系么……

有啊，现成库的运行效率可能会有很大的差别。

我查了CLR team的Blog，ms他们好像一直没对CLR进行什么优化，看来大部分精力还在于增加新的方法上

从.NET2.0到.NET3.5，CLR在功能上就没变过，怎么能说大部分精力都在增加新功能上呢。再说，CLR4.0在功能上的改进也很有限么，variance在CLR2.0就支持了，dynamic与CLR无关，改进的无非就是NOPIA，side by side, background gc之类。
但是从.NET2.0以来的每个service pack倒是都对CLR进行了更新，虽然细节不太清楚，但是性能优化应该也是有的，至少GC方面的优化是有的。