IBM has created Eclipse OMR, an open-source virtual machine toolkit to create runtime environments for any language. OMR aims at leveraging general improvements in virtual machine technology across languages, like garbage collection or hardware integration. To achieve this, IBM is generalising its own JVM, J9.
Although the JVM is increasingly becoming a generic runtime for a plethora of languages, its tight relationship with the Java language means a large part of its design and functionality is heavily linked to Java itself. This causes challenges when trying to use the JVM as a runtime for other languages, specially dynamically typed ones: up until the addition of InvokeDynamic in Java 7, dynamic languages had to to make use of inefficient workarounds to overcome the JVM's statically-typed nature, with significant impact to performance. As indicated by Daryl Maier and other members of the OMR project, this leaves language creators two choices: either create a runtime for the new language from scratch, which brings in prohibitive costs, or, as most teams have done, adapt the language to work with an existing runtime environment, accepting the limitations.
OMR provides a third option. Although OMR is not a runtime on itself, it is a toolkit to easily create runtimes. Created through refactoring components out of J9, IBM's Java Virtual Machine, OMR provides a language-agnostic implementation of the most common features of any runtime, together with a set of interfaces to create what the authors call "language glue", or language-specific code that will act as a bridge between the generic functionality provided by OMR and the particulars of the language at hand. Combining OMR with the language glue, language designers obtain a runtime that includes:
- Memory allocator
- Thread library
- Hardware abstraction layer to port the runtime to different platforms
- Event hook framework to connect to different runtime and OS events
- Trace engine for debugging and others
- Garbage Collection
- JIT compiler
In order to accelerate adoption, the interfaces for language glue don't need to be implemented completely from the outset, language designers can implement only parts of it depending on what runtime functionalities they want to obtain. For instance, one could have single-threaded mark / sweep garbage collection by simply implementing three of the APIs, while implementing more of them could also provide concurrent marking, parallelism or generational collection.
An interesting side effect of this refactoring is that the individual components are becoming easier to test. Prior to this change, components like garbage collection could only be exercised by using the runtime as a whole, which means testing required a lot of complex setup and analysis. However, after splitting and decoupling this complex logic, the individual parts can be tested in isolation, which simplifies test setup and analysis.
However, the most promising feature of OMR is probably the fact that it will be an open-source project run through the Eclipse Foundation (of which IBM is a strategic member). The project leaders hope that the Eclipse Foundation will foster a community of developers to provide innovative contributions to OMR, which then will be distributed to all languages that base their runtimes on this toolkit. This could help OMR gain terrain against OpenJDK which, although also open source, has traditionally suffered from some difficulties to incorporate interesting contributions, like for instance Google's performance improvements for CMS.
There are also downsides to this approach though. While forcing language designers to adapt to an existing runtime may present some challenges, it also means that the different languages can run simultaneously in the same virtual machine, therefore enabling language interoperability. OMR's approach of creating a different runtime for each language means interoperability will be much harder to achieve, if at all possible. The end result may be that different language designers will choose one approach or the other depending on their strategic priorities, weighing between ease of interoperability or ease of language development.