CLR和JVM的动态语言支持

作者 Charles Humble译者 韩锴 发布于 2008年2月21日 下午11时3分

社区

Ruby,

.NET,

Java

主题

动态语言

标签

IronRuby,

IronPython,

JRuby,

Jython

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

• 更早的 >