Eclipse OMR: the runtime plumbing shared by OpenJ9, Ruby and others

Runtime building blocks, not a runtime

Eclipse OMR is a set of open source C and C++ components that can be used to build language runtimes that support many different hardware and operating system platforms.

That distinction is the whole project. OMR is not a virtual machine, not a language, and not a complete runtime you can adopt and configure. It is the layer underneath, the parts that every managed language runtime ends up writing for itself: a garbage collector, a JIT compiler, a way to abstract the operating system, a threading library, tracing hooks, and a test harness.

The motivation is stated plainly in the project description of its own goal, which is to grow an open ecosystem of language runtime developers who can collaborate with hardware platform designers and operating system developers, so that language implementers can create more fully featured languages more quickly.

For a reader deciding whether this is relevant, the question to ask is whether you are writing a language runtime. If you are writing an application, an interpreter for a language you do not control, or a compiler that targets native code, OMR is the wrong shape of thing, because its components assume a managed heap, per-interpreter contexts and threads that a runtime owns.

The user is therefore a language implementer, usually a small team, who would otherwise spend years writing and porting the parts of a runtime that have nothing to do with their language. The trade is that you accept OMR's abstractions and its release cadence in exchange for not writing a collector from scratch.

Twelve components, from gc to fvtest

The component list in the README is the map of the project, and it reads as a list of the subsystems a managed runtime needs.

`gc` is the garbage collection framework for managed heaps, and it is the component most consumers care about. `compiler` holds the components for building compiler technology such as JIT compilers. `jitbuilder` sits on top of that as an easy to use high level abstraction, which is the difference between having a JIT you can call and having a JIT you have to drive yourself.

`port` is the platform porting library, and `thread` is a cross platform pthread-like threading library. `util` holds general utilities useful for building cross platform runtimes. `omrsigcompat` is a signal handling compatibility library, which sounds trivial until you try to install a signal handler on two operating systems with different models.

Two components are worth singling out because they are about operating rather than building. `omrtrace` is a tracing library for communication with IBM Health Center monitoring tools, which tells you about the origin of the code in a commercial context. `vm` provides APIs to manage per-interpreter and per-thread contexts, which is the layer a runtime uses to keep its interpreter state and its thread state apart.

`tool` is code generation tools for the build system, `example` is demonstration code showing how a language runtime might consume some of these components, and `fvtest` is a language-independent test framework so that OMR components can be tested outside of a language runtime.

That last one is the most underrated item on the list. Testing a garbage collector normally means embedding it in a language, but `fvtest` lets a component be exercised directly, which is what makes a component reusable in the first place. The `example/` directory in the tree shows the same idea, with a `gcmain.cpp` and a `glue/` directory, which is the shape a consumer's integration code tends to take.

Ten build targets, from AArch64 to z/OS

The build status table is the clearest statement of what this project actually is, and it is longer than most readers expect.

There is a Windows x86-64 build, Linux on x86, x86-64, AArch64 and 32-bit ARM, macOS on x86-64, Linux on 64-bit Power and AIX on 64-bit Power, Linux on z/Architecture s390x, and z/OS on s390x. Ten configurations, spanning five operating system families and five processor architectures, each with its own CI job on the Eclipse continuous integration server.

That spread is the project's real asset and also its real constraint. A component that has to work on z/OS, on AIX and on 32-bit ARM cannot assume a POSIX interface, cannot assume a 64-bit address space, and cannot assume anything about signal handling or thread creation. The `port` and `thread` libraries exist precisely to absorb that variability, and the constraint propagates into the code you write on top of them.

The z/OS and s390x entries are the ones that signal the heritage. Those targets exist because of the enterprise mainframe customer base, and a runtime component that has been made to work there has usually been made to work everywhere. The same breadth cuts the other way for a new consumer: a component that is portable to a 32-bit ARM Linux board is portable, and one that is portable to z/OS is portable in a way that is hard to argue with.

The build system reflects the same breadth. The tree carries `CMakeLists.txt`, `OmrConfig.cmake`, a `cmake/` directory, a `buildenv/` directory, plus the autotools side with `configure`, `configure.ac`, `config.guess`, `config.sub` and `install-sh`, and a `GNUmakefile` and `run_configure.mk` at the root. The `ddr/` directory and `ddr_artifacts.mk` are the debugging data record machinery, and `perftest/`, `nls/`, `sharedcache/`, `third_party/` and `scripts/` fill out the supporting infrastructure.

How a build is actually put together

The README does not contain a build tutorial, so the honest answer is where the instructions live rather than what they say. The repository root is the guide:

CMakeLists.txt
GNUmakefile
configure
configure.ac
install-sh
OmrConfig.cmake
cmake/
buildenv/

The `INSTALL` file sits alongside them and is the conventional autotools installation guide, which is the standard reference for the `configure` and `make` path. The CMake side is driven by `CMakeLists.txt` with `OmrConfig.cmake` as the package configuration, and `buildenv/` holds the environment and toolchain setup the CI jobs use, which is the part worth reading if you are building for an unusual target since it encodes the compiler and flag choices that upstream actually tests.

Two details in the tree suggest how the project is structured for its own development. `azure-pipelines.yml` with a matching `azure-pipelines.cache` file shows that the continuous integration runs on Azure Pipelines, and the badge links point at the Eclipse CI server, so there is more than one pipeline in the picture. `CODEOWNERS` shows the components are owned per area, and `SECURITY.md` and `CODE_OF_CONDUCT.md` sit at the root alongside `CONTRIBUTING.md`.

The release numbering is worth noting before you pick a version. The recent tags are omr-0.11.0 on 2026-10-05, omr-0.10.0 on 2026-07-13 and omr-0.9.0 on 2026-04-16, and the last push to `master` was on 2026-10-16. A steady quarterly cadence on a pre-1.0 version line says two things at once: the project is alive and shipping, and the API is still allowed to move between minor versions.

Who consumes it, and what Ruby and CPython had to do to

The README lists the consumers, and the list is more informative than a list of names usually is.

The most comprehensive consumer is the Eclipse OpenJ9 Virtual Machine, described as a high performance, scalable, enterprise class Java Virtual Machine implementation representing hundreds of person years of effort, built on top of the core technologies provided by OMR. OpenJ9 is where the bulk of the production experience sits, and a consumer picking OMR today is picking the code path that Java has been running for years.

The Ruby+OMR Technology Preview used OMR components to add a JIT compiler to the CRuby implementation and to experiment with replacing the garbage collector in CRuby. The phrase to notice is technology preview. The interesting part is the experiment, since replacing a mature Ruby's collector is exactly the kind of project OMR exists to enable, and a preview tells you the result was not production.

A SOM++ Smalltalk runtime has been modified to use OMR componentry, which is a second data point that the components are not OpenJ9-shaped.

The fourth entry is the one that needs care. An experimental version of CPython using OMR components has been created, but the README states it is not yet available in the open, and adds that the project's focus has been dominated by getting this code out into the open. So there is no CPython branch to look at, and you should not plan around one.

Taken together, the list says something about the intended adoption. OMR is not widely deployed across many languages, it is deeply deployed in one and experimentally explored in a few. That is a normal state for infrastructure of this kind, and it also means the most reliable guidance available to a new consumer is OpenJ9's own usage.

A choice of two licences, and what it costs you to depend on it

All Eclipse OMR project materials are made available under the Eclipse Public License 2.0 and the Apache 2.0 licence, and you can choose which to follow. The README's licence section links to the LICENSE file for the details, and the SPDX identifier in the source header spells out the full set of options: EPL-2.0, Apache-2.0, or GPL-2.0-only with the Classpath exception, or GPL-2.0-only with the OpenJDK assembly exception.

That is a genuinely useful choice rather than a formality. The GPL options with those exceptions are the ones that let a project be combined with the GNU classpath and OpenJDK assembly, which is what makes OMR usable inside a GPL-adjacent runtime. The Apache 2.0 option is what an organisation with an Apache-first policy will pick. The EPL-2.0 option is the Eclipse default and the one most likely to be a weak copyleft obligation for a modified component.

This is a description of what the licence file states rather than legal advice, and the practical step is to read the LICENSE file and pick deliberately, because the choice you make governs what you owe downstream.

The dependency cost is the other half. Adopting OMR means adopting a component set that is pre-1.0, moving on a quarterly cadence, and coordinated with an upstream that is tied to its largest consumer's needs. The OpenJ9 relationship is a double-edged fact: it means the code is exercised at scale, and it means the priorities are shaped by a Java VM's requirements.

There is a genuine alternative approach, and it is the one most projects should consider first. Writing your own collector and JIT layer gives you full control and zero upstream dependency, at the cost of years of work and a permanently open porting bug list. OMR is the trade of a shared codebase for a shared dependency. For a runtime whose garbage collection and JIT are not its differentiator, that is usually the right side of the trade. For a language whose entire premise is a novel execution model, the abstraction may be the wrong shape, and the `example/` directory exists so you can see how much of the glue you would write yourself.

Editorial conclusion

Adopt Eclipse OMR if you are implementing a language runtime and need a garbage collection framework, JIT compiler infrastructure, a porting layer or a threading library that already run on the platforms you target, since the alternative is reimplementing those layers and maintaining them across operating systems. Do not adopt it if you are building an application rather than a runtime, if you need a complete runtime rather than components, or if your licensing policy cannot accommodate the EPL-2.0 or Apache-2.0 dual option. Verify three things first: that the `gc` component's supported collectors and heap policies match what your language needs, that a build succeeds on your target with the toolchain in `buildenv/`, and that the version you take is one with a release tag near the 0.11.0 line, since the release numbering shows the project is still pre-1.0.

Frequently asked questions

Official sources

1. eclipse-omr/omr on GitHub
2. Issues
3. Project website
4. README
5. Releases