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=\u0026lt;invocation count\u0026gt;

\

我们还有几个其他的可调整的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