答复: C# 4 DLR & Java 7 Invokedynamic

原帖地址：C# 4 DLR & Java 7 Invokedynamic

呵呵，正好我也关注着这方面的内容。有兴趣的话楼主可以看看去年我写的些记录，这篇：LINQ与DLR的Expression tree（2）：简介DLR。

invokedynamic有机会比DLR具备更高的运行效率，主要是因为JVM的许多实现都比.NET的CLR要更“动态”。

以Hotspot JVM的运行模式为例，Java程序被装载进来后一开始主要是以解释模式执行，等到一定时间之后，某些方法变得比较“热”（执行密度高），就有机会被JIT为本地代码。根据JVM启动参数和程序运行状况的不同，Hotspot可能采取不同的JIT和优化策略。JVM可以假定程序大部分时间某些条件满足某些条件（例如持有某个锁的几乎总是同一个线程），并采用激进优化；如果运行到某一时刻，假定的条件不再满足了，HotSpot也可以退回到解释模式继续执行。整个过程中实际被执行的代码的状况是非常动态的。

CLR这边则总是在程序刚开始的就将每个调用到的方法都JIT为本地代码再执行。这样，唯一“动态”的地方就是：JIT之后的代码是放在一个所谓“代码堆”上的（与分代式GC管理的对象/大对象堆相互独立）；当这个堆的大小达到某个阈值时，CLR就会将JIT过的代码清空，然后重新开始托管方法调用->JIT->以本地代码执行的流程。（注：实际上桌面上的CLR在当前实现中是不抛弃代码的。.NET Compact Framework版的CLR倒是会抛弃JIT编译得到的代码）
CLR的指令集，MSIL（或者叫CIL）的设计使得它并不太适合于解释执行，因为指令本身是多态的。于此相对，JVM的指令集有许多是单态的，指令本身就包含了类型信息，更有利于解释执行时的效率。未来的CLR转向更动态的执行模型的可能性也因此受到了一些by-design的限制。

DLR为了支持动态语言中可能发生的方法重定义，或者是同一个方法调用点可能要调用不同类型对象的同名方法等状况，不得不提高运行时的动态性。与JVM增加invokedynamic指令不同，DLR的实现并不依赖CLR的任何改变；底下的CLR跟.NET 2.0时的CLR并没有大的变化。那怎么实现代码的动态性呢？DLR采用了更高层的抽象模型作为执行模型：Expression Tree。
DLR中每个方法调用点（CallSite）都保存着一些Expression Tree；基于DLR的动态语言实现也是将源码编译到Expression Tree之后交给DLR。这些Expression Tree可以被编译为MSIL变成动态方法（DynamicMethod），由CLR执行。DLR也会对代码做一些假设，满足假设的时候就重用以前编译好的动态方法，假设不成立的时候就重新构建Expression Tree，然后编译为MSIL得到动态方法，然后由CLR执行。

所以为什么invokedynamic有机会比DLR有更高的运行效率呢？因为JVM在底层实现了更多的动态性，以C++来实现了调用点的link/relink过程，Java一边只要说明link target是哪里，要满足的条件是什么就行；DLR则完全靠C#来实现调用点的link/relink过程，也靠C#或者其它.NET语言来说明link target与对应的条件。除非哪天C#能在速度上完胜C++，不然……嗯，呵呵。

不过实际东西出来之前谁也说不准。我也只能说invokedynamic有机会比DLR快，并不保证一定如此。至少，非Sun Hotspot JVM对invokedynamic的支持能有多好也得放入考虑之中。目前的DLR还有很大的改良余地，而invokedynamic也还只有prototype，还没达到最佳状态。让时间来告诉我们结果就是了～

P.S. 话说回来，使用更高级的语言来编程，长远来说倒也是更有潜力的；think Squeak，think Rubinius，think PyPy……