如何评价 IBM 的 Ruby + OMR？

本着没代码没真相的认真考察态度…这个问题暂时还无法回答。等它真的开源了再回来更新真正的内容。

2016-03-08更新：

OMR为其它语言运行时（language runtime）提供高性能、可移植、可维护的组件。目前它与其它运行时整合的策略是比较保守、渐进式的：以CRuby+OMR为例，它基本上只用最直观、最小改动的方式将OMR整合进去。像是说：

• JIT：IR生成策略基本上就是把YARV字节码解释器的实现原样翻译为Testarossa IL，而且后端优化并未完全开启；在遇到复杂字节码处理时调用回到CRuby运行时里。这样编译生成的代码兼容性有良好保证，速度虽然肯定会比YARV解释器去解释执行快，但是代码质量并不会很高，尚未发挥出Testarossa的全部潜力。
• GC：由于CRuby自身的GC只有mark-sweep，运行时的其它部分也都假定对象不会被移动，所以OMR整合进来时也只整合了mark-sweep GC进来，而compaction则作为“未来研究点”——其实是要说服CRuby社区放弃一些C API兼容性才可能整合进来。

总之就是，先想办法让OMR挤进圈子里，然后再想办法逐渐说服大家用上越来越多的OMR组件。

不够了解情况的同学可能会乐观的觉得有了OMR，CRuby的性能短板有望得到彻底解决。然而未来是否真的会如此发展，很大程度上取决于社区是否愿意改变自己，放弃一些向后兼容性，以便抛弃历史包袱、真正提升性能。

下面是讲故事时间。都是些废话，对八卦感兴趣的同学欢迎读下去。

=================================

其实去年年中就听说了消息说IBM在做这个项目，或许去年年底就会开源。

结果去年年底没等来OMR，却等到了微软把CoreCLR开源出来，让软粉们（包括我）都打了几管鸡血兴奋不已。

然后等等等…现在总算等到这个二进制预览版了。有东西发布总比一直憋着好 >_<

（话说不知道为啥IBM让Open Managed Runtime这个名字变成了黑历史，现在只把这个项目叫做OMR而且不说明代表啥缩写…）

正如同IBM在RubyKaigi 2015上的两个演讲所提到的：OMR即将开源。“即将”就是“尚未”，所以这次的Ruby+OMR Preview的Docker镜像里又怎么会有OMR的源码呢…

下载了那个Docker镜像的同志们你们肯定会跑到 /home/rubyomr/ruby 去看那个Git repo。没错，它包含了IBM在CRuby 2.2.2的基础上整合OMR所需要改动的所有代码，但是不包括任何OMR自身的代码。

——这些都在

里写得很清楚了。没啥意外。

今年8月初去参加JVM Language Summit 2015的时候，我有机会跟主导OMR项目的老大之一Mark Stoodley聊了一下。感觉挺好玩的。下面写写从“局外者”视角看到的故事。

大家开源自然各有各的算盘，有希望增加影响力的，有希望借助社区力量帮忙报bug修bug移植新平台的，有项目快死了交给社区接盘的。现在各大软件公司都在积极参与开源，把许多以前难以想像能开源的、比较核心的项目拿出来。形成了一股潮流之后，许多公司（或者其中的某些小组）可能就坐不住了：自己的竞争对手可能已经把项目核心代码毫无保留的开放了出来，而自己的产品与对手的产品本来就是在同等技术水平，这样：

• 一来，自己的产品可能就没有保守“秘密”的必要了——别人开源出来的代码能做得一样好；
• 再来，别人先开源了可能会吸引社区的关注，获得影响力和社区支持；
• 况且，对许多开发人员而言，能与外界无隔阂的交流自己所做的项目，总是有种爽快感。这是在商业公司里参与开源项目的开发者的一大乐趣。

看看当下流行的编程语言平台，有多少项目是已经开源了的？就拿与IBM J9最直接竞争的对手来看：

• Oracle/Sun的HotSpot VM已经随着OpenJDK完整的开源了。没开源的部分都是Oracle新加的一些增值功能，并不影响JVM的核心功能。
• Oracle JRockit被Oracle舍弃后已经不再是IBM J9的竞争对手了。JRockit的创始团队多次尝试说服Oracle管理层允许将JRockit的核心代码开源出来，但是都被否决了（可惜）；
• 微软的CoreCLR 、CoreRT、LLILC等项目把.NET Framework的CLR的许多核心功能都开源了出来
• CoreCLR是传统的运行.NET程序的运行时，包括微软产品的CLR/CoreCLR的基本上所有核心组件：GC、新的RyuJIT等都在其中；
• CoreRT是为.NET Native做AOT编译场景而优化的运行时；
• LLILC是新写的基于LLVM的JIT/AOT编译器

延伸出去，现在仍然大热的JavaScript语言的主流高性能实现，也尽数是开源的（或即将开源）：

• Google V8
• Mozilla SpiderMonkey（系列）
• Apple JavaScriptCore
• Microsoft Chakra：Microsoft/ChakraCore · GitHub

上面列举的都是实现上技术水平相近的编程语言平台，大家都开源了。

那么IBM留着自己的J9 VM不开源有什么好处呢？基本上什么好处都没有。

而且J9不开源的话，它的开发者们心里得多痒痒啊。跟Mark聊天的时候我能感受到他对前几年在IBM开发J9/Testarossa的一些郁闷：

• IBM的技术体系比较封闭，而且出于知识产权保护的原因，J9必须是一个clean room实现。J9的开发是完全不允许接触OpenJDK的HotSpot VM源码的，所以也无法公开跟同行们交流细粒度的信息；
• 对IBM来说，实现编程语言平台的产品组就是个cost center，只花钱不赚钱，所以也不肯拨给他们多少经费出去参加活动，据说前几年连去参加些相关的学术会议都不容易批下经费（回复里有TR的开发大大指正说TR整合在Cobol工具链中是有卖钱的）；
• 许多“新”语言的兴起使得IBM在自己传统支持的语言之外需要额外支持些别的实现，例如JavaScript、Ruby等等。显然IBM有尝试研究V8，在其基础上做改进以及移植到IBM自有的一些平台上（看IBM SDK for Node.js）；对其它语言的实现应该也有所研究吧。

这种工作繁重又封闭的环境实在是让人难以振奋。需要来点什么重新点燃激情的事情做做。

没错，那就是开源，跟外面的大家一起玩。

但是商业公司做什么事情都得有个确切的由头。IBM J9组想出来的就是结合PaaS的大趋势，描述一番IBM要支持的系统平台和语言平台有多少，工作量有多大，如果这些平台能共享一些IBM已有的先进技术组件有多好，等等。

换个角度说，J9作为一个完整的JVM想要开源出来可能会牵扯到太多方面。不知道IBM和Oracle/Sun的协议具体规定了IBM能做什么不能做什么呢。

但是，J9 VM毕竟是IBM自己写的clean room实现，只要把J9 JVM中的“J”——Java——去掉，IBM想怎么开源别人都没话说。

这就引出了我们现在所看到的OMR的形式：一套可以用于实现编程语言运行时的技术组件，但不是一个完整的VM。

引用IBM在RubyKaigi 2015上两个演讲的其中一个：

（打不开请自备工具）

图中的方框就是一个（相对高性能的、跨平台的）托管运行时（managed runtime）的组成部分。其中红色的是OMR项目提供的组件，包括：

• JIT编译器：Testarossa
• GC套装：一套GC框架Modron，包括多种GC实现：mark-sweep、mark-compact、copying的串行、并行、并发等多种实现。IBM未来有可能会连Metronome实时GC也开源出来。
• 平台抽象层（PAL）：抽象出底层操作系统提供的服务为统一的API，便于上层的运行时能在平台间移植。
• 监控、诊断、跟踪服务（monitoring / diagnostics / tracing，或者叫RAS - Reliability, Availability, and Serviceability）：IBM已经有许多现成的命令行和可视化工具可以分析和诊断托管运行时的运行情况，只需要在运行时里插入合适的埋点即可。

那么缺少的是什么呢？黑色的方框。而这些正好是一门语言的实现的最基本部分：语言的字节码编译器、字节码解释器等等。

这些是理解和执行一门编程语言的“基础”，没有它们，就算有OMR提供的组件也什么都做不到。

这样就正好跟一些现成的语言运行时互补了：它们已经实现了基本的运行时，但是可能技术水平不够高，可能没有优秀的GC或JIT编译器。OMR便是在这里派上用场。

这其实并不是IBM第一次尝试把J9的技术移植给其它语言的运行时了。

不过对J9的核心产品组而言，这倒是第一次做这样的尝试。也因为是核心产品组在做这件事，OMR看起来比之前的尝试靠谱许多。

之前都是IBM Research或者一些相对边缘的产品组做的，例如为CPython做的Fiorano，以及为PHP5做的P9。这俩项目最终都失败了，均以出了篇论文后就无人问津告终。