CLR 和 JVM 的动态语言支持

近日，几名 Sun 的工程师参加了.NET 语言座谈会，John Rose 和 Charles Nutter 向在座的广大.NET 听众介绍了 Sun 的 Da Vinci Machine 项目。这个项目乍看起来和 Microsoft 的动态语言运行时（DLR）非常相似，它们的目标都是提高各自的虚拟机对动态语言的支持。但是，它们却采取了完全不同的方法。

DLR 在很大程度上是基于 Jim Hugunin 在 IronPython 上的工作的。DLR 是一些库和工具的集合，它可以帮助人们更容易地在.NET CLR 上实现动态语言。DLR 为编译器和解释器的代码生成 (通过语言无关的表达式树)、快速动态调用 (通过自我更新的动态调用点)、跨语言的方法分发和类型系统的支持提供了便利。DLR 的主要工作已经完成了，其中包含了 DLR 上层的库以及对底层 CLR 的修改，以便于 CLR 与 DLR 的集成。

Da Vinci 项目的范围是很广泛的，包括了动态和函数性语言。它是基于 JSR-292 的，后者是 Sun 的 JVM 参考实现的一个实验性的分支，它将为 Java 虚拟机实现多个扩展的原型，以使非 Java 语言能够以与 Java 自身相当的性能有效地在虚拟机上运行。Da Vinci 中最主要的子项目是实现动态调用，它可以提供一种机制，使得语言编译器可以编译一个非 Java 的调用点（call site），一个特定于语言的处理器会在运行时决定调用点的连接指令（linkage）。连接指令对于动态参数类型是敏感的，它可以被更新或者废除。Da Vinci 还包含了数目众多小型的子项目 ，包括增加对尾调用和尾递归（通过一个新的 tailcall字节码前缀）、三元体（使用一个新的tagged tuple签名字符）的支持。其目的在于至少让 Da Vinci 的一些特性成为 Java SE 7 虚拟机规范的一部分。

John Rose 在 blog 上谈论了 JVM 和 CLR 对于新兴的编程语言持续增加的兴趣：

“（用于 IronPython 和 IronRuby 的）DLR 又一次证明，我们即将迎来编程语言设计的一次复兴。由于一些原因，人们重新开始大规模地创造新的编程语言了，并渴望获得关注。我认为，“一些原因”是指更优秀的工具、更高级的运行时、更便宜的 CPU 周期和开源运动这些因素的综合效应。”

Rose 还比较了 Da Vinci 机器和 DLR 之间的类似之处：

“DLR 是基于 CLR 的，另一方面 Da Vinci Machine 是基于 JVM 的。根据我在 JVM 上的经验来说，我知道我所用的技术都是来自于 Smalltalk、Self 和 CLOS 的经过了时间考验的。我的同事（和竞争者）已经开始证明这些方法的实用性了。”

由于在实现 DLR 时，尽量保持它对 CLR 自身干扰的最小化，因此很多涉及到 DLR 的工作都关注于如何在 CLR 之外为动态语言提供更好的性能。Rose 指称，这在 Java 世界中完全是不必要的，因为 JVM JIT 已经囊括了相当多的有成效的优化技术。Charles Nutter 在他的 blog 上也记录下了类似的结论： > “…另一方面，CLR（目前）还无法达到 JVM 动态优化的层次。尤其是它现在还不支持反优化代码（deoptimizing code），而这些代码已经被编译成本机代码（JIT 化，JITed）了，而且 CLR 通常（偶尔？很少？）都不会将类型信息考虑到如何优化代码上来。如果要让动态语言运行得更好，你就必须做一些额外的工作。你无法得到一个静态调用路径，它可以提前 JIT 并且相信它不会再变化。你无法将一个调用点与特定的方法体绑定。最后，这意味着你必须自己来实现这些功能，你需要进行剖面、自我更新调用点（根据收集到的信息构建规则和目标集）”

当然，每种方法都是有利有弊的。Microsoft 所采用的基于库的方法，其投入市场的时间更短，而且每次更新都能独立于 CLR 发布。Sun 的方法可以产生更好的性能（即使没有 Da Vinci，JRuby 已经在一项性能测试中表现得比原始的 C 版本的 Ruby 更优秀了），但这样做就必须要忍受过长的开发周期带来的开销。 查看英文链接： Dynamic Languages on the CLR and JVM