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

在编程武林中，Java派成立较久底子雄厚，虽然掌门人Sun已经老态龙钟，镇山之技的Java语言已经被后进的新秀.NET派的C#压得喘不过气来，甚至有时候Sun老大还得跑到.NET派潜伏学艺。但是百足之虫，死而不僵，一众Java派的拥趸们自认虽然Java渐渐技不如人，但是Java派成立日久，从Java演化过来的七十二门绝技绝非武林暴发户.NET派所能比拟，其中几大支派如apache，springsource各有绝技，而衍生出的帮会、黑社会等等更是不计其数，.NET派望尘莫及。

然而江湖传言有不世神功叫北冥神功，“北冥有鱼，其名为鲲，鲲之大，不知其几千里也……”，能够容纳几千里的大鱼必定是非常广阔的海洋，因而北冥神功正是寓含了广大恢宏之意，也体现了神功的威力。“可以吸取他人的内力以供己用，是迅速提升功力的捷径。内力既厚，天下武功无不为我所用，犹如北冥，大舟小舟无不载，大鱼小鱼无不容。”

.NET派的几位高人闭关苦练，竟然悟出北冥神功，此神功后曰：IKVM.NET.

江湖后辈小子Ray Linn偶习此神功，得心得一二，不敢自珍，特此记之，以壮大我.NET门派，千秋万代，一统江湖。

那日Ray偶来到apache支派，却看到Apache弟子们各施绝技，好不热闹. Ray对Apache绝技手痒已久，想来得习IKVM.NET已有时日，斗胆上前叫阵。迎战者哪Apache派中的小弟子，江湖人称:commons.collection.

二人拳脚来去，Ray却懒得与之多动手脚，随即默念真言：

ikvmc -assembly:commons -target:library -version:1.0.0.0 commons-collections-3.2.1.jar  

collection陡然萎靡在地，想是一身内功尽被Ray所吸去，Apache派人等尽皆失色，“我等苦练十余载，内力尽为汝一夕取去”，莫敢上前。

Ray回转.NET派，试练collection的神功，借助IKVM.OpenJDK.Core之神器，神功即成，试演如下：

using System;

using org.apache.commons.collections;
using org.apache.commons.collections.functors;

namespace MyLib
{
    class Program
    {
        static void Main(string[] args)
        {
            String name = "Tim";
            Predicate nameJohn = new EqualPredicate( "John" );
            Predicate nameTim = new EqualPredicate( "Tim" );
            Predicate instanceString = new InstanceofPredicate(typeof(String) );
            Predicate instanceDouble = new InstanceofPredicate(typeof(Double));
            Console.Out.WriteLine( "Is Name John?: " + nameJohn.evaluate( name ) );
            Console.Out.WriteLine("Is Name Tim?: " + nameTim.evaluate(name));
            Console.Out.WriteLine( "Is this a String?: " + instanceString.evaluate( name ) );
            Console.Out.WriteLine( "Is this a Double?: " + instanceDouble.evaluate( name ) );

        }
    }
}

相较原有神功：

import org.apache.commons.collection.Predicate;
import org.apache.commons.collection.functors.*;
String name = "Tim";
Predicate nameJohn = new EqualPredicate( "John" );
Predicate nameTim = new EqualPredicate( "Tim" );
Predicate instanceString = new InstanceofPredicate( String.class );
Predicate instanceDouble = new InstanceofPredicate( Double.class );
// Testing all predicates for "Tim"
System.out.println( "Is Name John?: " + nameJohn.evaluate( name ) );
System.out.println( "Is Name Tim?: " + nameTim.evaluate( name ) );
System.out.println( "Is this a String?: " + instanceString.evaluate( name ) );
System.out.println( "Is this a Double?: " + instanceDouble.evaluate( name ) );

竟然绝无二致。

偌大Java江湖，从此为我.NET所用，哇哈哈。

评论

30 楼 幸存者 2009-12-29  

ray_linn 写道

这里我想到如果实现动态ngen--似乎更美妙，只ngen到被调用的那些方法，可以称为动态ngen或者静态hotspot

动态ngen？和jit有什么区别？除非把native code保存到磁盘上，那倒算是有区别，不过那样似乎就把ngen和jit的缺点都占了——既不能动态优化，又必须在运行时编译。

29 楼 ray_linn 2009-12-29  

RednaxelaFX 写道

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之类的功能也是相当难实现的，明显是有这样的需求才会引出这样的设计。

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

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

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

28 楼 ray_linn 2009-12-29  

RednaxelaFX 写道

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

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

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

27 楼 ray_linn 2009-12-29  

RednaxelaFX 写道

ray_linn 写道

icewubin 写道

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

我仔细查了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测）

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

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

26 楼 RednaxelaFX 2009-12-29  

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

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

25 楼 RednaxelaFX 2009-12-29  

ray_linn 写道

icewubin 写道

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

我仔细查了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测）

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

24 楼 RednaxelaFX 2009-12-29  

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_linn 写道

icewubin 写道

有不少现成的Java库的实现尤其是JDK，是根据JVM的特点优化和改进，甚至于放弃有些无用的优化

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.

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肯定也会有大幅度的动作的 =_=|||

23 楼 ray_linn 2009-12-29  

icewubin 写道

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

我仔细查了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测）

22 楼 ray_linn 2009-12-29  

幸存者 写道

ray_linn 写道

幸存者 写道

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

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

library应该不关clr team的事吧。

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

21 楼 幸存者 2009-12-29  

ray_linn 写道

幸存者 写道

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

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

library应该不关clr team的事吧。

20 楼 ray_linn 2009-12-29  

幸存者 写道

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

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

19 楼 幸存者 2009-12-29  

ray_linn 写道

RednaxelaFX 写道

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

我查了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方面的优化是有的。

18 楼 ray_linn 2009-12-29  

RednaxelaFX 写道

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

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

17 楼 icewubin 2009-12-29  

RednaxelaFX 写道

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

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

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

16 楼 RednaxelaFX 2009-12-29  

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

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

15 楼 ray_linn 2009-12-29  

icewubin 写道

有不少现成的Java库的实现尤其是JDK，是根据JVM的特点优化和改进，甚至于放弃有些无用的优化

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，并未有太多问题。

14 楼 coolbi 2009-12-29  

观看高手们的较量

13 楼 icewubin 2009-12-29  

ray_linn 写道

icewubin 写道

问题是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的。

12 楼 ray_linn 2009-12-29  

icewubin 写道

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

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

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

11 楼 icewubin 2009-12-29  

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

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