查尔斯·奥利弗·纳特论“红宝石变种人”


Strange Loop conference是在圣路易斯举行的一次独特的软件开发者会议,有出色的演讲者,以及各种各样的语言和技术。以下是对查尔斯的采访,讨论他的Strange Loop Talk"Ruby Mutants",这将探索他的Ruby-Java混合语言Duby和Juby。Duby是带有静电类型的Ruby,而JUBY使用的是Ruby语法和动态类型,但是直接在JAVA类型系统上工作。

Charles Oliver Nutter@headius)因其在JRuby,基于JVM的Ruby实现。在Sun工作期间,他也是JVM团队所做工作的热情早期采用者JSR 292 and invokedynamic以允许更灵活的方法调用,这是动态语言所需的关键功能。最近,查尔斯和JRuby团队的睡觉离开了Sun,搬到了著名的Ruby PowerhouseEngine Yard,它看到对部署在JRuby上的应用程序的需求增加。

奇怪的循环:嗨,Charles,我想知道您是否能告诉我们JRuby目前与其他Ruby实现相比处于什么位置。显然,它有其他产品所没有的Java集成故事,但是它在兼容性和性能方面处于什么地位呢?为什么会有人选择JRuby而不是另一个实现呢?

Charles:就Ruby实现而言,我们是最完整、最兼容的替代Ruby。我们是唯一一家拥有Production Rails用户的公司。我们认为1.8.6/7兼容性在很大程度上是一个“解决”的问题,除去我们将永远做的一些小修复。

我们也是在实际应用程序上表现出明显更好性能的唯一替代方案。对于几乎所有用户来说,Rails现在都比Ruby 1.8快得多,与1.9不相上下,尽管我们还没有开始向JRuby添加任何与1.9相关的优化。在微基准方面,我们的表现甚至更好;速度足够快,以至于一些仅限MRI的商店现在为大型数据处理任务运行JRuby。

除了性能之外,JRuby还提供了真正的并行本机线程,这使得JRuby能够在拥有多个内核的现代系统上更好地伸缩。在可选的Imp中,只有三个支持并行线程,其中只有两个可以运行Rails,并且只有JRuby可以快速运行。我们是目前运行实际应用程序的最佳替代Impl。

我认为JRuby被证明是一个非常优秀的Ruby实现。

奇怪的循环:在JDK 7中,JSR 292正在探索JVM级别需要哪些功能来支持动态语言。JRuby可能是新技术最明显的早期采用者invokedynamic bytecodemethod handles。您似乎看到这些功能带来了显著的性能改进。您能解释一下为什么它们对动态语言如此重要吗?它们是如何提高性能的?

查尔斯:直到最近,动态语言还有点萎靡不振,因为它们不仅缺乏静电类型语言提供的保证,还缺乏静电类型语言的性能。随着Javascript VM大战以及CLR和JVM开发人员对动态语言支持的新关注,这种情况发生了很大变化。在JVM的情况下,它以优化的动态调用支持的形式出现:invkedynamic字节码。

JRuby是第一个(也是唯一个)拥有全功能调用动态支持的JVM语言,它为动态调用带来的简单性令人震惊。我们还没有看到期望中的性能提升,但是HotSpot的工程师们才刚刚开始对InvokeDynamic进行优化。事实是,动态语言比静电类型的语言更适合许多问题领域。如果他们也有表现,你付出的唯一惩罚就是缺乏静电输入保证。在当今多国语言的世界里,您应该能够在动态代码和静电代码之间随意移动条,而不会受到性能影响。InvokeDynamic和类似的工作将使JVM语言实现这一点。

奇怪的循环:您认为JVM还有哪些特性是最重要的?尾部调用、fixnum支持和接口注入等特性似乎都在候选列表中。在JRuby中,哪些附加功能会带来最大的不同?

Charles:我有一个相当简短的JVM特性列表,我想看看:

Tail calls:JVM应该支持优化的通用尾部调用。实际上,MLVM项目中有一个补丁添加了这一点,我相信正在形成一个JSR来尝试将其引入Java7,但它还没有出现,我们非常怀念它。

Interface injection:这是通过在运行时提供实现接口的代码,将任何对象视为实现给定接口的能力。它有点像JVM的“运行时扩展方法”。由于这是许多JVM语言都可以使用的特性,因此该功能目前正在进行中,并附加到了InvokeDynamic JSR中。例如,它允许我们将所有java.util.List实现者视为实现了支持JRuby的“Array”接口,并将JRuby视为始终是Ruby数组来传递。这将使将Java的类型与任意语言的类型组合在一起变得容易得多。

Fixnums and/or value types:我们在性能上肯定会被超越的为数不多的地方之一就是数值运算。JRuby中的1+1涉及比Java多得多的逻辑,因为Java将其视为对两个32位整数基元的基元“加”运算,并将其优化为尽可能快的本机代码。

问题源于我们的调用逻辑只支持对象目标和参数。这意味着我们通常必须对所有值进行装箱,因此我们既要支付执行动态调用的成本*,也要支付对数字进行装箱和取消装箱的成本。其他Ruby实现能够传递Fixnumber的“标记指针”,并且在执行数学运算之前只需支付很小的位掩码成本。如果我们在JVM中有原生的fixnum支持,理论上我们可以拥有几乎与原始数学一样快的完全包装箱的数学运算。但目前还没有人在做这件事。

Delimited continuations(协例程):Ruby1.9增加了旋转“纤程”的能力,“纤程”是轻量级的类似线程的实体,不需要新的本机线程,但可以随时进行分支。在JRuby中,因为我们不支持从给定调用堆栈分支(并保留),所以我们必须使用本机线程实现纤程。如果JVM支持延续(实际上我们只需要“分隔的”延续),我们将能够通过随意交换调用堆栈来更有效地实现纤程。MLVM中有一个可以继续支持的补丁,但是由于未解决的安全问题,没有计划将其移植到Java7中。

奇怪的循环:很多人对engine Yard聘用三个主要JRuby开发人员的举动感到惊讶。为什么engine Yard认为有必要增加他们对JRuby的承诺?

Charles:Engine Yard与我们接触是因为,简单地说,他们看到了对JRuby的大量需求。他们还对发展Ruby世界感兴趣,让Java开发人员使用Ruby可能是实现这一目标的最快方式。我们对迁移到Engine Yard感到非常兴奋,我们从Ruby爱好者、JRuby爱好者和JVM语言爱好者那里收到的回应都非常令人兴奋。有一家专注于Ruby的公司推动JRuby向前发展,这将是一件很棒的事情,这也意味着我们可以更容易地与Java世界中对JRuby感兴趣的每个人合作。这对所有参与其中的人来说都是一场胜利。

奇怪的循环:JRuby和Java集成的未来是什么?我想您将在Strange Loop上谈论的Duby和Juby项目是探索未来集成替代方案的方法吗?

查尔斯:绝对是。Duby是对静电类型的“类Ruby”语言在JVM上的外观和感觉的探索,我想到目前为止我已经能够证明,只需进行很小的修改,您就可以从静电类型的替代语言中获得很多Ruby的优点。Juby项目是我尝试探索一种完全基于InvokeDynamic的语言,以了解调用协议可以变得多么简单,以及与普通Java类型和对象的集成可以变得多么紧密。这两个都将提供给JRuby工作。

就JRuby的内置Java集成而言,与Groovy或Scala等语言相比,我们现在正在填补剩余的空白。到目前为止,从Ruby代码生成“普通”Java类是不可能的,这意味着像JPA或JAX-RS这样的反射或注释性API不能用JRuby实现。但是,经过几个小时的工作,JRuby的主分支已经包含了使Ruby对象真正成为*成为*Java对象所需的大部分管道,这些对象具有外观正常的类,这些类是可反射的,具有正常的签名,并且支持注释。很快,我们将探索拥有一个做同样事情的脱机编译器,早期的工作是在"ruby2java"项目。一旦我们可以创建正常的Java类,基本上就没有我们不能支持的Java集成功能了。就Java而言,JRuby将与Groovy并驾齐驱,我们仍将忠实于Ruby。

怪圈:谢谢,查尔斯!我等不及要听你在Strange Loop的演讲了!

了解有关Strange Loop的更多信息: