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

ms我说的是新的“方法”--- 就是说一大堆新的class library上

library应该不关clr team的事吧。

俺的意思是, Hejsberg的精力全在.net的新功能上（比如声明性编程，动态，并发），根本还顾不上CLR这头，所以CLR team偷偷懒（或者没有足够的资源），小小打些补丁也就够了。

我仔细查了jruby的性能提升之道，有几点，1.改进了parser 2.改进了AST，提供了转换成byte code的机会，因此有机会利用jvm的jit，并未发现有。。何代码是为jvm而设计。


当然说jruby是最快的ruby 1.8实现是有点前提的，因为ruby.net和jruby不在同一个组里，而ruby.net也比ruby快。（jruby在linux上和ruby测，ruby.net在windows上和ruby测）

CLR team又没有偷懒…….NET 2.0到3.5都能用同一个规格的CLR正好反映了CLI的设计在很大范围内满足现有需求了；但规格是表面，内里是进化还是在不断推进的。
2.0的时候对泛型的支持、对接口方法分派的实现的改变，2.0 SP2/3.5 SP1时对值类型的标量替换，4.0的尾调用改进等等，都是CLR中JIT可见的进步。每个SP对GC参数的调整，未来对String的进一步优化，NGEN生成代码的方式的改善（不只是4.0对代码脆弱性的改善，还有之前3.5对代码布局的改进等）都是（或将是）CLR别的部分的可见改进。In-proc SxS之类的功能也是相当难实现的，明显是有这样的需求才会引出这样的设计。

BCL小组虽然跟CLR小组有联系但各自的关注点明显不同…… =_=|||
VSL（Visual Studio Language）小组跟BCL、CLR小组的关注点又不一样了。Anders是在VSL这边的……


ray大大所说的“冷”JIT那就不是just-in-time啦，是ahead-of-time，AOT。NGEN是把CLR中的JIT编译器以AOT的方式用于将装有MSIL的程序集在程序运行前事先编译为native code。是AOT。
NGEN代码并不总是对启动速度有利——读磁盘很耗时间，native code比MSIL大很多，如果读入了大量没被立即用到的代码的话反而还亏了。NGEN在3.5做的优化与减少这个开销有关。

桌面的CLR的JIT怎么看都跟放在运行时执行的静态编译器没啥不同。它所能利用到的运行时信息主要是已经被JIT过的非虚方法的入口地址——在为这些方法生产call时可以生成为一个直接call。然而CLR的JIT不能内联虚方法，甚至不能内联有复杂控制流的的方法（复杂指的是非直线型代码）；也不会根据程序运行中的模式来调整生成的代码（例外是对接口方法的调用与委托的Invoke()中的trampoline）。HotSpot较于CLR则动态得多也激进得多，把虚方法当作非虚方法调用、对虚方法内联、对方法中的部分代码暂时不生成实际代码（而是生成uncommon trap）、对同一段代码生成多个版本的代码（multi-versioning）。这才是“动态编译器”至少该做到的。而IBM的人还笑话HotSpot说跟DK for Java与Jikes RVM相比HotSpot更像是静态编译器……可以想像在动态性/自适应性方面CLR跟VM的前沿技术已经有很远的距离了。

不过话说回来，有需求才会推动结果。看JScript一直那么慢吞吞的，周围的JavaScript对手们都变得超强了，IE9里的JScript引擎也就用上了跟对手们一样的技术来优化，速度马上就起来了……如果哪天Java以速度作为卖点开始侵蚀.NET的市场的话，CLR肯定也会有大幅度的动作的 =_=|||

JRuby的优化方法有很多，其中不少是从HotSpot team交流学习来的、模仿HotSpot的优化方式。不介意的话可以读读相关资料，Distilling JRuby: Method Dispatching 101，Headius: The Power of the JVM
hmm

JVM的性能进步对上层应用的影响不可谓不大。其中一个有趣的侧面是Sun的javac：从JDK 1.3开始它就会忽略-o编译开关——Sun认为在Java源码到JVM字节码过程中的优化没多少必要，反正HotSpot能提供足够优化。虽说这个设计到底是不是真的合理还可以商榷……

JVM的实现自然也会影响到库的实现。之前正好记过一篇关于反射调用方法的一个log，也算是能扯上关系。

ironpython 铁了心要切换到DLR上，不知道切换到dlr之后性能是否下降了些

这里俺理解的应该是为javac优化IL而特别设计的库，因为IL之后所以jit就为CLR而不是JVM所接替了,当然JVM做的优化，CLR就享受不到了，不过同样CLR的优化,jvm也享受不到

就是觉得这些改进过于琐碎，卖友立竿见影影响performance，有点急了。

这里我想到如果实现动态ngen--似乎更美妙，只ngen被调用的那些方法，其他继续保持il,可以称为动态ngen或者静态hotspot,这里基于大部分用户只是在CLR运行某些程序。