IBM创建了Eclipse OMR，一个用于为任何语言创建运行时环境的开源虚拟机工具包。OMR旨在让各种语言都能利用虚拟机技术的一般改进，像垃圾收集或硬件集成。为此，IBM正在推广自己名为J9的JVM。

\\

虽然JVM日益成为许多语言的通用运行时，但它同Java语言的紧密关系意味着其设计和功能的很大一部分都是同Java本身紧密相关的。这就使得在尝试使用JVM作为其他语言的运行时时会遇到挑战，尤其是动态类型的语言： 在Java 7引入InvokeDynamic之前，动态语言都不得不使用低效的变通方案来克服JVM的静态类型特性，严重影响了性能。就像Daryl Maier和其他OMR项目成员所说的那样，这给语言创建者两种选择：要么从头开始为新语言创建一个运行时，这会带来难以承受的成本，或者，就像大多数团队所做的那样，调整语言，让它可以使用已有的运行时环境，接受它的限制。

\\

OMR提供了第三种选择。虽然OMR本身不是一个运行时，但它是一个让你可以轻松创建运行时的工具包。OMR是通过重构IBM Java虚拟机J9的组件创建出来的，对于任何运行时中最常见的功能，它都提供了一种语言无关的实现，同时，它还提供了一套接口，用于创建接口作者所说的“语言胶水（language glue）”或者是特定于语言的代码，作为OMR提供的通用功能同需要处理的语言细节之间的桥梁。将OMR同语言胶水相结合，语言设计者就可以获得一个包含如下功能的运行时：

\\

• 内存分配器 \\
• 线程库 \\
• 用于将运行时移植到不同平台的硬件抽象层 \\
• 用于连接不同运行时和操作系统事件的事件钩子框架 \\
• 用于调式及其他目的的跟踪引擎 \\
• 垃圾收集 \\
• JIT编译器\

为了促进推广，语言胶水接口并不需要从头全部实现，语言设计者可以根据他们想要获得的运行时功能仅实现其中的一部分。例如，简单地实现这些API中的三个就可以获得一个单线程的标记/清除垃圾收集功能，而实现更多的接口就可以获得并发标记、并行或分代收集功能。

\\

这次重构有一个有趣的副作用，就是单个组件更容易测试了。在这次修改之前，像垃圾收集这样的组件只能使用整个运行时来执行，这意味着测试需要大量复杂的设置和分析。不过，在对这个复杂的逻辑进行分隔和解耦之后，单个组件可以隔离测试了，这简化了测试设置和分析。

\\

不过，OMR最有前途的特性可能是它将成为一个由Eclipse基金会（IBM是其战略成员）运作的开源项目。项目负责人希望Eclipse基金会培养一个开发者社区，为OMR提供创新性贡献，所有以OMR工具包为基础创建运行时的语言都可以从中受益。这有助于OMR攻占OpenJDK的领地，后者虽然也是开源的，但它在吸收有价值的贡献时一直有些困难，比如谷歌对CMS所做的性能改进。

\\

然而，这种方法也有缺点。虽然迫使语言设计者采用一种已有的运行时可能会带来一些挑战，但那也意味着不同的语言可以同时在同一个虚拟机中运行，这样就便于语言互操作。OMR为每种语言创建一个不同的运行时的方法意味着，即使可能，实现互操作也要困难许多。最终的结果可能是，不同的语言设计者根据自己的战略重点，在易于互操作和易于语言开发之间作出权衡，选择这一个或其他方法。

\\

查看英文原文：IBM Kick-Starts Eclipse OMR, a Toolkit for Creating Language Runtimes