CLR 和 JVM 的动态语言支持

  • Charles Humble
  • 韩锴

2008 年 2 月 21 日

话题:Java.NETRuby语言 & 开发

近日,几名 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

Java.NETRuby语言 & 开发