IBM has been working hard on their own flavor of the Java Virtual Machine (JVM) -- J9 JVM -- since 1997. J9 was built as a closed source (proprietary) independent implementation of the JVM whose class libraries were based on the licensed Sun (now OpenJDK) implementation. J9 has many enhancements and flag-bearing optimizations including: tiered compilation; shared classes; escape analysis; hardware specific optimizations, such as selecting the correct large page size; soft real-time garbage collector; API optimizations via Apache Harmony, dynamic ahead-of-time (AOT) compilation; several object locking specific optimizations; and more.

Since version 5, IBM's J9 JVM has been offered in IBM's Java Development Kits (JDKs). For Windows platform, the JDK is bundled and shipped with IBM's Websphere Application Server (WAS). For Linux, AIX, z/OS and IBM I platforms, the JDK (also known as SDK, where S stands for Software) and the corresponding Java Runtime Engine (JRE) can be downloaded from IBM DeveloperWorks'; Downloads' page, and also pulled from DockerHub at https://hub.docker.com/_/ibmjava/ . Form factors include SDK, JRE, small footprint Java (sfj) or alpine.

The Eclipse OMR Project

In early 2016, IBM open sourced the core, non-Java parts of the J9 runtime environment under the Eclipse OMR project. The OMR project is a language-agnostic runtime toolkit. More details on the Eclipse OMR project can be found in this presentation by Dr. Mark Stoodley, OMR project co-lead: https://www.slideshare.net/MarkStoodley/omr-a-modern-toolkit-for-building-language-runtimes

Below are a few slides from the above presentation that give an overview of the OMR project.

For Java, the language runtime could be shown as below:

If we had to show a similar runtime for Ruby, it would look as shown in this slide:

If we substitute Ruby for Python, the runtime environment blocks would be identical to Ruby. This made it clear to IBM that they could organize the J9 runtime into layers for core runtime components as shown in the slide below:

Accordingly, the OMR project could be constructed as a collection of language agnostic runtime technology components that can be used to build runtimes for Java, Ruby, Python, and other languages.

The OMR project has the following components:

• A garbage collection framework for managed runtime heaps. This includes the mark-sweep, the generational and the parallel scavenge garbage collectors (GCs)
• A virtual machine API to manage per interpreter and thread contexts
• A compiler for native code generation
• Diagnostic services aka “Health Center” to help with live analysis of GC and other runtime details as well as method profiling abilities
  • A trace library helps provide communication with the monitoring tools
• Few libraries such as port, thread and util to provide platform abstraction and cross platform runtime abilities. There is also a library for signal handling.

IBM engineers have built runtimes and JIT compilers for the following languages, based on OMR components:

Ruby, Python, SOM++ (Smalltalk), a Lua JIT called Lua Vermelha, a JIT for the Rosie Pattern Language, a partial JIT for Swift, as well as tutorial JITs and runtimes for Base9 (a simple Javascript like runtime) and Kaleidoscope, the tutorial language used by the LLVM project. This is, of course, in addition to building their own production SDK for Java 8 from the OMR project.

More information on the Eclipse OMR project can be found here:

• If you want to learn more about Eclipse OMR: http://www.eclipse.org/omr
• If you want to build/use Eclipse OMR for your runtime needs: https://github.com/eclipse/omr
• If you have feedback please provide it to the team mailing list: omr-dev@eclipse.org
• Contributors will need to sign the Eclipse CLA: http://www.eclipse.org/legal/CLA.php

The Eclipse OpenJ9 Project

This article started with a brief overview of IBM’s J9 JVM, and until 2016/7 J9 was closed source. Since then it has been moved to the Eclipse Foundation as an openly governed open source project, and renamed to OpenJ9. IBM saw the impact of the open source community and as J9 is a central component within IBM’s Java offerings, they aspired to encourage development within the open, and ultimately to engage with the larger open source community. From September 2017 the Eclipse OpenJ9 has been an open source project within which IBM and others work together on the J9 JVM.

OpenJ9 consumes Eclipse OMR and itself fits into the Java class libraries from OpenJDK 9 and future releases, as shown in the next two slides from a presentation made by Dr. Stoodley @JavaOne 2017: https://www.slideshare.net/MarkStoodley/javaone-2017-mark-stoodley-open-sourcing-ibm-j9-jvm

More information on OpenJDK with OpenJ9 can be found in the above presentation. A few useful links are listed here:

• To download binaries for OpenJDK with OpenJ9, please go to: https://adoptopenjdk.net/nightly.html?variant=openjdk9-openj9
• To get involved with the community: https://github.com/eclipse/openj9. Contributors will need to sign the Eclipse CLA: http://www.eclipse.org/legal/CLA.php
• The Eclipse OpenJ9 web site can be found here: https://www.eclipse.org/openj9
• The Docker images (built nightly by AdoptOpenJDK) from OpenJ9 can be found here: https://hub.docker.com/r/adoptopenjdk/openjdk9-openj9/
• To interact with the people working on the project and check out the (weekly) happenings: https://www.eclipse.org/openj9/oj9_whatsnew.html
• Eclipse OpenJ9 0.8 release plan: https://projects.eclipse.org/projects/technology.openj9/releases/0.8/plan

OpenJ9 with OpenJDK 8

The ability to download, build and run OpenJ9 with OpenJDK 9 was a great achievement for the Eclipse OpenJ9 project. However, because Java 9 is not a long term supported (LTS) release, many developers are still using Java 8, and it became clear that there needed to be a port of OpenJ9 for OpenJDK 8.

In November 2017, just two short months after becoming an open source project, Eclipse OpenJ9 announced that OpenJDK 8 could be built with OpenJ9 (https://www.eclipse.org/openj9/oj9_build.html) and also announced the availability of downloadable binaries at the AdoptOpenJDK project: https://adoptopenjdk.net/releases.html?variant=openjdk8-openj9

According to the Eclipse OpenJ9 for Java 8 article, "the Eclipse Open J9 project uses a single code stream to implement the JVM across all supported Java releases, from Java 8 to Java 9 and beyond." Through this single stream development model Eclipse OpenJ9 aims, as much as possible, to provide JVM technology advancements for all currently supported JDK levels at the same time. Of course, some JVM enhancements are tied to language-level changes that are purposefully targeted at major Java release boundaries, and Eclipse OpenJ9 will respect those choices so that programmers can continue to rely on the solid Java platform that they know and love.

The above article also points users to the OpenJ9 performance page which has DayTrader 3 application benchmark test results comparing OpenJDK 9 with OpenJ9 to OpenJDK 9 with HotSpot VM.

A quick look at those charts highlights the benefits of shared classes and ahead-of-time (AOT) compilation strategy in reducing startup times for large applications running on the OpenJ9 JVM, as shown in this graph from the article:

The article also notes that OpenJ9 consumes only half the memory footprint of OpenJDK with Hotspot, even when load is applied to the system, while providing equivalent performance. As cloud and Platform as a Service (PaaS) deployments are typically priced by the megabyte per time unit, running in half the memory footprint could potentially save significant amounts of money for certain use cases.