对 Eclipse OMR（用于创建语言运行时环境的工具集）架构师 Mark Stoodley 的访谈

IBM 的 Eclipse OMR 是一个开源的虚拟机工具集，用于创建任意语言的运行时环境。它的意图在于让实现语言的人能够重用 IBM 在 Java 运行时方面所投入的数百开发人年所取得的成果，能够受益的包含已有的语言如 Ruby、Python、Javascript 等等，它还能加快新语言的创建过程。

该项目真正意识到了在开发人员中，存在语言多样性这一客观现实。语言运行时可以从重用其他语言的组件方面受益。它的理念在于，尽管每种语言都有自己的定位，但是它们实际上会有相同或类似的组件。比如说，一个全新的语言可以使用来自 Java 的分代垃圾收集器，不必再重复造轮子，完全不用关心这个语言的语法和表现形式与 Java 的语法完全不同。

InfoQ 采访到了该提议的架构师 Mark Stoodley。

InfoQ：IBM 在 Java 运行时方面已经投入了数百的开发人年和上百万美元，现在为什么这么做呢？是不是 IBM 不会在 Java 领域进行重点投入了呢？

Mark Stoodley：并非如此，IBM 在 Java 生态系统中投入了很多，而且将会持续投入。但是，我们希望这么巨大的投入也能为其他的语言社区带来红利。
随着像 IBM Bluemix 这样的云平台的流行以及微服务架构的发展，相比于几年前，我们需要更广泛地关注语言多样性的问题。我们的客户关注很多不同的语言，因此我们也必须要关注这些不同的语言。对于 IBM 来说，以跨语言社区的方式，高效利用投资是非常重要的，我认为并不是只有 IBM 面临这样挑战，这就是我们致力于构建 Eclipse OMR 社区的原因。
因为几乎所有的现代语言都是开源的，所以对于我们来说参与进来并发挥差异性的最佳方式就是将自身开放出来。实际上，Eclipse OMR 就是 IBM 加入已有的开放社区，用来构建语言运行时，而不是关起门来自己进行研究。

InfoQ：Eclipse OMR 项目是否致力于让更新的语言从中收益，这些语言指的是还没有发明的或者还没有进入开发人员的视野的？它能够帮助已有的语言吗，如 Ruby、Python、Javascript 等等？

Mark Stoodley：实际上，两方面都可以！
Eclipse OMR 组件在与某个语言的运行时集成时，需要实现我们所谓的“语言胶水层（language glue layer）”。基本上来讲，这些代码就是帮助 OMR 组件实现特定语言的语法和行为。我们努力让这个胶水层尽可能简单和直接地描述该语言对 Eclipse OMR 组件的需求。
例如，某个语言的运行时需要告诉 OMR GC 如何循环访问内存区域中的值（也就是对象）来查找指向其他内存区域（对象）的指针。这个过程是与语言运行时所采用的对象模型密切相关的，所以它需要作为该语言胶水层的一部分，用来支持 OMR GC 组件。返回的指针将会被 OMR GC 组件所使用，保证这些对象处于存活的状态。至于在任意机型，任意数量的内核上高效地遍历完整的对象图，OMR GC 就知道该怎么做了。
搭建一个简单的标记 - 清除（mark-sweep）收集器并使其运行起来相对来讲比较简单，只需要实现几项内容即可。更为复杂的收集器如分代的 GC 技术，则需要编写内存屏障（barrier），这需要的工作会更多一些。但是我们正在努力寻找使其更加简单的方法，也欢迎任何有志于使它变得更好的人参与进来。对于构成 Eclipse OMR 项目的每一个组件，都有类似的来历。
填充语言的胶水层通常会涉及到重构已有运行时的一些代码，或者为新的运行时从头进行编写。但是，如果你要编写自己的运行时的话，这些代码很可能也是必须要编写的。通过使用 OMR 的组件，你能够编写更少的代码，获得更好的功能。

InfoQ：你能在技术上总体介绍一下 Java 的运行时组件吗，有哪些组件已经可以进行重用了？还有哪些组件是最近就可以重用的？

Mark Stoodley：IBM 已经贡献了 20 万行的代码，其中包含了多个现在就可以使用的不同组件：

1. 垃圾收集（GC）
2. 平台抽象层（端口）
3. 跨平台线程库（线程）
4. 运行时结构：当构建运行时的时候，全局以及每个线程可用的上下文

我们只是为 GC 组件添加了通用的支持，这样的话，就将我们主要的 Java GC 技术开放了出去，可以供其他语言来使用。我们正在做一个诊断工具，帮助运行时的开发人员编写和调试语言运行时相关的问题。我们正在努力地让即时编译（Just In Time，JIT）技术能够开源，预计今年晚些时候就能完成了。编写 JIT 编译器是一项艰巨的任务，我们也在为 JIT 做一个更简单的接口，这样人们就能更快地准备就绪并使其运行起来，不用再去担心编译器开发人员日常所关心的所有细节。

InfoQ：Eclipse 为什么开源这个项目呢？

Mark Stoodley：这个过程其实就是确保每个人都可以访问我们的项目并且自由地使用这项技术，不管你是完成班级项目的学生、尝试一些酷炫事物的 hacker、与开源社区协作或者在社区内工作的公司，甚至是想构建自己的业务，也没有意愿为社区做出什么回馈的人，都可以使用这些技术（但是，我们希望这些人都能够看到回馈社区所带来的价值！）。
Eclipse 基金会提供了我们所需的可信环境和基础设施，确保我们的知识产权（intellectual property，IP）在得到保护同时，还能保证它们的自由访问。这个环境能够让我们非常舒服地进行开放开发，知道我们的 IP 是安全的，我认为其他人也能感受到同等程度的舒适。随着时间的推移，我们也希望能够从 Eclipse 项目中收益，它们具备构建平台的实际经验，其他人能够使用、扩展这些平台，并为其做出贡献，这完全匹配 Eclipse OMR 项目的初衷。
Eclipse 基金会对我们来说，是完全适合的。

InfoQ：我认为，从短期来看，Java 社区所能得到的收益应该是最少的。你认为 Java 运行时能够在这个共生的关系中最终收益吗？

Mark Stoodley：绝对会这样的。 Eclipse OMR 项目是用来共享运行时方面的技术投资的，这些技术能够跨多种不同的语言，其中也包括 Java，它想围绕实现语言运行时的人群构建一个社区。具有共享、可重用的组件对社区来讲是很棒的一种方式，不管人们来自何处都能分享他们的最佳实践。IBM 通过贡献其 Java 平台的一些技术来帮助培育这个社区。Eclipse OMR 是一个开放的项目，具有开放的贡献规则：任何人都可以为其做出贡献，项目的提交者欢迎各种类型的贡献提交，我们致力于扩大提交者的数量，鼓励社区为 OMR 组件贡献内容，包括为已有的组件进行功能增强，或者贡献 / 构建 OMR 尚未包含的全新组件。
我们期望其他的语言能够影响 OMR 的众多组件，例如，我们认为比 Java 更加动态的语言将会帮助 Java 本身更好地适应动态语言。
所以，我坚定地认为 Java 将会在这里有所收获，就像其他的语言在这里会有所收获一样：没有人能够垄断伟大的创意。但是当我们通过可重用的运行时技术组件共享这些伟大的创意时，整个开发社区都能从中受益。

InfoQ：你们有证据证明这种重用工作的实际可行性吗？并不仅限于学术练习方面的证据？

Mark Stoodley：我们已经进行了一些探索性的工作，以此来证明 Eclipse OMR 组件不仅能够用在一种语言上：目前是 Java、Ruby、Python 以及一个 Smalltalk 运行时，名为 SOM++，它是用来教授学生如何构建运行时的。我们知道它是可以运行的：我们已经设法将方法 profiling、垃圾收集以及即时编译器技术从 Java 迁移到到了 Ruby、Python 以及 SOM++，如果大家感兴趣的话，都会将其贡献给社区。
不过，现在的工作还没有完成。我们的目标就是想证明 Eclipse OMR 理念从开始就是可行的。事实上，我们的工作完成得要超过该目标：即便开始的需求是不能破坏已有运行时的兼容性，我们依然做了许多很酷的事情。通过使用 IBM Health Center 工具，为我们的 Ruby 和 Python 实现集成了方法 profiling 功能，确定了工具 API 能够引入到 OMR 中，然后可以非常容易地用于多种语言运行时，从而提供内置的监控功能。我们将自己的 Java GC 技术用在了 Ruby 所有的非堆数据上，使其变成了受托管（可垃圾回收）的堆，这样的话，在内存占用方面会有更好的控制，并且带来了性能提升，因为受托管的内存会比原生内存分配和释放得更快。最后，我们实现了相对简单的即时编译（JIT）器，只用了几千行代码，尽管我们对其没有报太大的希望，它还是将性能提升了两倍。这些 JIT 编译器可以进一步完善，从而提供更好的性能，但是我们认为这些工作可以在社区内部或围绕社区来做，随着 Eclipse OMR 项目的成熟，我们希望在这种类型的事情上能够做更多的工作。
Ruby+OMR Technology Preview 能够运行 Rails 应用，即便将 Ruby+OMR JIT 功能开启也可以，这证明了它的兼容性，其 GitHub 地址是 https://github.com/rubyomr-preview/ruby 。我们欢迎大家的反馈，所以尽可以下载并尝试一下！
另外一个明显的样例是 IBM JDK 本身。J9 开发团队已经开始从 IBM JDK 中提取 Eclipse OMR 组件，在这个过程中，推出了 IBM JDK 的 Java 8 版本。我们并没有在其他的分支上开展这项工作，在进行这项工作的同时，大的开发团队在持续开发和发布 IBM JDK 8，带来了令人印象深刻的新特性和全面的性能提升。我们正在构建下一个版本的 IBM JDK，同时还要顾及到 Eclipse OMR 项目所带来的变化。这对于我们来说，并不是学术练习：这关系到我们是如何构建自己的运行时的。
如果其他的语言社区对 Eclipse OMR 组件能够给它们的运行时带来什么变化感兴趣的话，我们也期待针对其他的语言社区开展工作。

InfoQ：有没有公司或社区已经针对 OMR 项目开展工作？能谈一下它的下一步规划吗？

Mark Stoodley：目前，Eclipse OMR 项目主要还是活跃在 IBM 的开发人员之间，这并不是因为我们不想让别人和我们一起工作！该项目依然处于初期阶段，这就意味着它还缺少好的文档和对新人的培训。这些也是我们非常想进行提升的领域。除了核心技术相关的提升并将所有相关的内容全部开放出来以外，我们也在构建文档和接触其他人。我们欢迎任何对它感兴趣的人下载该项目，地址是 https:// github.com/eclipse/omr，即便只是告诉我们你想做什么都可以。
我们目前正在为 Ruby 社区提交一些 pull request，从而让社区考虑将 OMR 组件接受到下一个 Ruby 的主版本中。我们目前基于 Ruby 2.2.5 版本，可以参考 https://github.com/rubyomr-preview/ruby ，我们正在努力将这些补丁添加到 Ruby 的主分支中，同时还在将其重构为更小、更易管理的提交内容，这些提交内容会通过 OMR 实现特定的功能。
但是，这只是已有的团队成员正在做的事情。我们欢迎任何想参与该技术的人，不管你是在做语言平台、与语言进行交互的工具、语言所运行的平台还是其他的框架（通过与不同的语言进行紧密集成，这些框架可能会从中受益）。我们目前确实处于先有鸡还是先有蛋的初始阶段，但是借助你们和其他人的帮助，我们将会进行扩展，并且会在越来越多的语言社区上开展工作，从而兑现承诺，交付可共享、可重用的组件来构建运行时环境。
我期待在 Eclipse OMR 社区能够看到你们！

在 InfoQ 之前的一篇文章中，我们曾经介绍过该项目的发布。

查看英文原文： Q&A with Mark Stoodley, Architect of Eclipse OMR Toolkit for Creating Language Runtimes