GeeCON 2017: Charlie Gracie - Eclipse OMR your (J)VM toolkit

### Overview In this GeeCON 2017 presentation, Charlie Gracie, a senior software developer at IBM and garbage collection architect for the IBM J9 JVM, introduces the Eclipse OMR project. Originally originating internally as the "Open Managed Runtime," the project does not provide a managed runtime itself, nor is it linked to the Eclipse IDE. Instead, it is an open-source (dual-licensed under Apache v2 and EPL v1) toolkit hosted by the Eclipse Foundation consisting of language-agnostic components extracted from IBM's J9 JVM. The goal of Eclipse OMR is to provide reusable virtual machine building blocks—such as platform abstraction, threading, garbage collection, JIT compilation, and diagnostic tooling—allowing language runtimes to share robust, high-performance runtime infrastructure without imposing language semantics.

### Key Topics - **Rationale and Mission**: Modern cloud platforms rely heavily on multiple language runtimes (e.g., Java, Node.js, Ruby). While runtimes share common architecture components (bytecode interpreters, memory managers, platform layers, diagnostic services), their implementations are typically siloed, requiring repetitive effort to exploit modern hardware capabilities. Eclipse OMR aims to eliminate duplication by providing a modular, language-agnostic toolkit without fracturing existing runtime communities. - **Component Decoupling**: Unlike approaches like running languages entirely atop the JVM or CoreCLR, OMR does not impose an execution model or object semantics. Components can be consumed independently (e.g., swapping a single-threaded GC for a parallel GC, adding platform portability, or integrating a JIT compiler) via lightweight glue layers. - **OMR Architecture**: The toolkit contains 800,000–900,000 lines of code across several core modules: - *Port and Thread Libraries*: Abstract OS and platform calls across supported architectures (x86, Power, z/Architecture/s390, ARMv7) and operating systems (Linux, Windows, AIX, z/OS). - *Garbage Collector (GC)*: Scales from a simple mark-sweep GC (which can be brought up in under 100 lines of glue code) up to parallel, generational, concurrent, or region-based collection. - *Compiler Framework and JITBuilder*: An extensible intermediate language (IL) compiler backend derived from IBM compilers, complemented by JITBuilder—a high-level API wrapper that simplifies JIT generation without requiring deep compiler IL knowledge. - *RAS and Diagnostic Tooling*: Lightweight event tracing into rolling buffers, Diagnostic Data Router (DDR) for post-mortem structure inspection and core dump analysis, and verbose GC output compatible with tools like GC Memory Visualizer and IBM Health Center.

### Technical Details & Case Studies Gracie reviews several integration prototypes demonstrating OMR's practical impact: - **Base9**: A minimal educational stack-based interpreter supporting primitive types, used to demonstrate OMR JIT integration. Implementing JIT compilation via JITBuilder achieved over a 100x speedup on benchmarks such as Fibonacci in under a day of work. - **SOM++**: A minimal Smalltalk C++ virtual machine. Integrating OMR's parallel GC delivered an immediate >2x throughput improvement. Later adding JITBuilder yielded a 3x to 30x speedup across the benchmark suite in roughly 3–4 weeks of development. - **Lua (PUC-Rio)**: Integrating OMR JIT required fewer than 50 lines changed in Lua itself and roughly 2,000 lines of JITBuilder code to map opcodes. To combat the performance penalty of dynamic typing ("death of a million type checks"), developers implemented type specialization guards, dropping benchmarks like Mandelbrot from 17 minutes to approximately one minute. - **OpenJ9**: IBM consumes OMR back into its production J9 development stream on an hourly basis. Gracie notes IBM plans to open-source the remaining JVM components under the OpenJ9 project.

### Takeaways Eclipse OMR provides a modular, production-hardened foundation for building or modernizing virtual machines. Rather than rewriting complex memory managers, platform abstraction layers, and JIT compilers from scratch, language developers can integrate OMR components incrementally using C or C++ glue code while retaining existing language semantics and tooling compatibility. Next steps for the project include improving open documentation, expanding multi-platform testing infrastructure, and growing community engagement across academic and research groups.