JRuby 新 IR 奠定未来性能提升之路

  • Mirko Stocker
  • 丁雪丰

2009 年 11 月 29 日

话题:RubyJVM语言 & 开发架构

JRuby 在——性能方面已经取得了重大进步。早在一年前,它就是最快的 Ruby 1.8 实现了。每次发布 JRuby 的性能都会得到提升,有了 Subbu Sastry 开发的新中间表示(Intermediate Representation,IR),可以预见到其性能将有更进一步的改善。

InfoQ 采访了 Subbu,希望了解新的 IR 是什么样的,它将为 JRuby 带来什么好处。在讨论新的中间表示前,编译器目前是如何在没有 IR 的情况下工作的?

严格说来,AST(抽象语法树)也是一种 IR——因为它既不是源代码,也不是目标语言。理论上来讲,IR 是一种表示方法(内存数据结构,输出“汇编”等),它不但可以用于捕获源语言的语义,还能够让语言的实现更为顺畅。

鉴于 JRuby 是从解释器起家的(这是获得语言的参考 / 原型实现的最好方法,也是最简单的方法),并且它必须完全兼容 C MRI 实现,由于 MRI 实现是以 AST 为基础的(或者存在其他原因),JRuby 在起初选择 IR 时使用了 AST。

JRuby AST是解析器的输出结果,仅仅是源代码的树形表示,包含不同种类的节点,例如有类、方法和变量。工具还能用它来分析代码,例如,可以提供自动化重构。)

在过去的几年里,出于对性能的考虑,开发了将 AST 转换为本地字节码的编译器,这样一来,既可以降低解释的成本,HotSpot 又能进行优化(内联等),还可以编译为硬件级本地代码。虽然我认为可以将编译器部署为 AOT(ahead-of-time)编译器,但它其实并不会盲目地编译所有东西,只有当方法执行计数器超过某个阈值时它才会生效。

Tom Enebo 补充道“JIT 阈值只是一个方法调用计数器。可以用下面的设置来配置(现在的默认值是 50)该计数器:

   -J-D jruby.jit.threshold=<invocation count>

我们还有几个其他的可调整的 JIT 参数,例如控制 JIT 多少个方法”。相比 AST,新的表示方法是什么样的呢?

AST 对解释而言还不错,但如果要用它来实现“传统的”(和其他 Ruby 特定的)编译器“优化”,AST 可能就不是 IR 的最佳选择了。新的 IR 会将 AST 翻译成一系列指令,它们有点类似高级汇编。一条指令就是一个简单的操作(分支、调用、接收参数、返回等等),它会操作一组操作数(可以是变量、整数、浮点数、数组、闭包等等)。起初,很多操作都以调用方法结束,但我们期望以后一些操作能被优化(内联等)成本地(本地 JVM 等)操作。

(如果想要知道 IR 是什么样的,请参见JRuby 邮件列表中的文章。)

IR 中还会包含一组其他的数据结构,例如控制流程图(用于表示控制流程)、类及方法层次,以后可能还会有静态单赋值形式(Static Single Assignment,SSA)这样的更好的优化。自始至终,IR 的目标就是用正规的形式来表示源代码,同时还要保留尽可能多的来自前端的信息。在编译器运行之时,较高层次的 IR 指令可能会被拆分成较低层次的 IR(调用会被拆成查询、方法表加载和分派),或者将其他隐式信息会变为显式的(堆帧分配、堆帧加载和存储),这样它们才能得到进一步优化。

作为一组“汇编”指令,新 IR 在表现上也更线性——不是树形的——但正如上面所说的,其中还有其他辅助的数据结构(图)用于显式地表示控制流,偶尔还有数据流。

新的 IR 还能带来什么好处吗?

新 IR 更适合用来实现传统编译器优化。此外,我们还打算试验一些技术——(a) 内联闭包 (b) 内联方法调用 (c) 在拆箱时将整数 / 浮点数调用转换为原生的整型 / 长整型 / 单精度浮点型 / 双精度浮点型运算 (d) 对于非内联闭包,降低其堆加载 / 存储开销……可能还有一些别的内容。这些东西用 AST 做起来会相对困难一些。

我们还希望这个 IR 消耗更少内存(如果实现得当的话,这是理所应当的)——只有在优化阶段才出现内存峰值。作为操作的正规表示形式,它也许能提供简单的解释器实现(基于 IR 指令)。相对于 100 多个 AST 节点类型而言,基于 IR 的解释器只需要几十种指令即可。

对于何时 IR 会被用于 JRuby 中,目前是否已经有计划?

我们预计能够从新 IR 中获得收益还要花上一段时间。我不想胡乱说个时间点,免得将来自己打自己的嘴巴,这应该是水到渠成的事情。对我而言,这是个有趣的项目 :-)

我们计划第一步要构建一个基于新 IR 指令操作而非 AST 节点的解释器。这能帮助我们建立信心,告诉我们已经捕获了所有需要捕获的信息,验证我们的关于提升解释器性能的假定(毕竟,我们有可能完全弄错了),为实现性能分析提供基础(相应的,这会告诉编译系统应该关注哪些地方)。

新 IR 已经部分完成了(还有一些 AST 节点尚未处理),其中包括控制流程图、一些本地优化、数据流框架、一些数据流分析和审查和闭包堆加载 / 存储优化,未来几个月里还会加入更多内容。

简而言之,我不认为有什么别的选择能在 JVM 上构建分层的 Ruby 实现,原因很简单,Ruby 和 JVM 之间在语义上并不匹配。我们不能期望 JVM 优化所有 Ruby 的动态语义,这是另一个很长的话题了。

GitHub 上能找到新 IR 的代码。

查看英文原文:JRuby's New IR Paves the Way for Future Performance Improvements

RubyJVM语言 & 开发架构