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

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) 内联方法调用©在拆箱时将整数 / 浮点数调用转换为原生的整型 / 长整型 / 单精度浮点型 / 双精度浮点型运算 (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