IBMは1997年から彼らのJava仮想マシン (JVM) -- J9 JVM -- に精力的に取り組んできた。J9はクローズドソース (プロプライエタリ) な、独立したJVMの実装としてビルドされていた。クラスライブラリはライセンスされたサン (現OpenJDK) の実装をベースにしていた。J9には拡張やフラグによる最適化が数多くあり、次のようなものがある。階層型コンパイル、クラス共有、エスケープ解析、的確なラージページのサイズ選定といったハードウェア固有の最適化、ソフトリアルタイムなガベージコレクタ、Apache HarmonyによるAPI最適化、動的な事前 (AOT) コンパイル、オブジェクトロック固有の最適化をいくつか、などである。

バージョン5から、IBMのJ9 JVMはIBMのJava開発キット (JDKs) で提供されている。Windowsプラットフォームでは、JDKはIBMのWebsphereアプリケーションサーバ (WAS) に同梱して出荷されている。LinuxやAIX、z/OS、IBM Iプラットフォームでは、JDK (SDKとしても知られる。Sはソフトウェアを表す) と対応するJava実行エンジン (JRE) はIBM DeveloperWorksのダウンロードページからダウンロードできる。また https://hub.docker.com/_/ibmjava/ のDockerHubからもプルできる。形成する要素としてはSDKやJRE、小フットプリントなJava (sfj)、alpineがある。

Eclipse OMRプロジェクト

2016年の初め、IBMはコアの、J9の実行環境の非Java部分をEclipse OMRプロジェクト下でオープンソースにした。OMRプロジェクトは言語非依存のランタイムツールキットである。Eclipse OMRプロジェクトの詳細はOMRプロジェクトの共同リードであるMark Stoodley博士のこのプレゼンテーションにある。https://www.slideshare.net/MarkStoodley/omr-a-modern-toolkit-for-building-language-runtimes

上記のプレゼンテーションからOMRプロジェクトの概要を解説したスライドを何枚か以下に掲載する。

Javaでは、言語ランタイムは以下のようになる。

Rubyに同じようなランタイムがあるとすると、このスライドが示すようになるだろう。

RubyをPythonに置き換えると、実行環境のブロックはRubyとまったく同じになるだろう。IBMがJ9のランタイムを以下のスライドが示すようにコアランタイムコンポーネントに対するレイヤにまとめた理由がよくわかる。

その結果、OMRプロジェクトは言語非依存のランタイム技術コンポーネントとして構築できている。JavaやRuby、Python、その他言語向けのランタイムとして使える。

OMRプロジェクトには以下のようなコンポーネントがある。

• 実行時に管理されているヒープ向けのガベージコレクションフレームワーク。これにはマーク&スイープや世代別、並行scavengeガベージコレクタ (GCs) が含まれる。
• インタプリタやスレッドのコンテキストごとに管理するための仮想マシンAPI。
• ネイティブコード生成向けのコンパイラ。
• メソッドプロファイリングだけでなくGCやその他実行時の詳細の即時分析に役立つ診断サービス、“Health Center”。
  • トレースライブラリがモニタリングツールとのやり取りを支援する。
• プラットフォームの抽象化し、クロスプラットフォームなランタイムを可能にする、ポートやスレッド、ユーティリティといったごく少数のライブラリ。またシグナル処理用のライブラリもある。

IBMのエンジニアは以下の言語を対象にOMRコンポーネントをベースにしてランタイムとJITコンパイラも構築してきた。

RubyやPython、SOM++ (Smalltalk)、Lua Vermelhaと呼ぶLuaのJIT、Rosie Pattern Language用のJIT、Swift用局所JIT、およびBase9 (簡単なJavascript風のラインタイム) とKaleidoscope向けの学習用JITやランタイム、LLVMプロジェクトで使われている学習用言語。もちろんOMRプロジェクトから彼ら独自のJava 8向け製品SDKを構築することに加えて、だ。

Eclipse OMRプロジェクトの詳細はここにある。

• Eclipse OMRについてより学びたいのであれば: http://www.eclipse.org/omr
• ランタイムへの要件に対してEclipse OMRを構築/利用したいのであれば: https://github.com/eclipse/omr
• フィードバックがあればチームのメーリングリストへ: omr-dev@eclipse.org
• コントリビュートにはEclipse CLAへの署名が必要です: http://www.eclipse.org/legal/CLA.php

Eclipse OpenJ9プロジェクト

この記事ではIBMのJ9 JVMの概要から始める。2016年7月までJ9はクローズドソースだった。それからEclipseファウンデーションへ移管し、オープンに管理されるオープンソースプロジェクトとなり、OpenJ9と改名した。IBMはオープンソースコミュニティの影響を見て、J9をIBMのJava提供物の中で中心的なコンポーネントとしながらもオープンな空間で開発が促進されることを、究極的にはより大きなオープンソースコミュニティと結びつくことを熱望していた。2017年9月からEclipse OpenJ9はIBMと他がJ9 JVMに対して一緒に作業できる場所である、オープンソースプロジェクトとなった。

OpenJ9はEclipse OMRを利用し、それ自身はOpenJDK 9や今後のリリースにあるJavaクラスライブラリと適合する。JavaOne 2017でのStoodley博士が行ったプレゼンテーションからスライドを2枚次に示す。https://www.slideshare.net/MarkStoodley/javaone-2017-mark-stoodley-open-sourcing-ibm-j9-jvm

OpenJ9が付属したOpenJDKについての詳細は、上記のプレゼンテーションにある。役立つリンクをここに記しておく。

• OpenJ9が付属したOpenJDKのバイナリダウンロードはこちらから: https://adoptopenjdk.net/nightly.html?variant=openjdk9-openj9
• コミュニティへの参加は: https://github.com/eclipse/openj9。コントリビュータはEclipse CLAへの署名が必要です: http://www.eclipse.org/legal/CLA.php
• Eclipse OpenJ9のwebサイトはこちら: https://www.eclipse/org/openj9
• OpenJ9のDockerイメージ (AdoptOpenJDKによる夜間ビルド) はこちら: https://dockerhub.com/adoptopenjdk/openjdk9-openj9
• プロジェクトに従事している人とのやり取りや (週間で) 起こっていることの確認は: https://www.eclipse.org/openj9/oj9_whatsnew.html
• Eclipse OpenJ9 0.8のリリース計画: https://projects.eclipse.org/projects/technology.openj9/releases/0.8/plan

OpenJ9とOpenJDK 8

OpenJDK 9でOpenJ9のダウンロードやビルド、実行ができるようになったのはEclipse OpenJ9プロジェクトでの大きな成果だ。しかし、Java 9は長期間サポート(LTS)リリースではなく、多くの開発者は依然としてJava 8を使っており、OpenJDK 8向けのOpenJ9のポートが必要なのは明らかだ。

2017年11月、オープンソースプロジェクト開始からわずか2ヶ月でEclipse OpenJ9はOpenJ9 (https://www.eclipse.org/openj9/oj9_build.html) でOpenJDK 8をビルドできると発表し、AdoptOpenJDKプロジェクトからバイナリをダウンロードもできると発表した: https://adoptopenjdk.net/releases.html?variant=openjdk8-openj9。

Java 8用Eclipse OpenJ9という記事によると、"Eclipse Open J9プロジェクトはJava 8からJava 9以降までサポートするJavaリリースすべてにわたってJVMを実装するため、単一のコードストリームを使っている"。この単一ストリーム開発モデルでEclipse OpenJ9は現行でサポートするJDKレベルすべてに対して可能な限り同時にJVM技術の進歩を提供することを目指している。もちろん、JVM拡張のいくつかは主要なJavaのリリース境界を対象にした言語レベルの変更に明らかに結びついており、プログラマが理解し愛するJavaの堅牢なプラットフォームを継続して信頼できるように、Eclipse OpenJ9はこうした選択を尊重している。

また上記の記事ではOpenJ9のパフォーマンスページをユーザに提示している。DayTraderの3つのアプリケーションのベンチマークでOpenJ9を使用したOpenJDK 9とHotSpot VMを使用したOpenJDK 9のテスト結果を比較したものがそこにある。

こうした図を素早くチェックすると、OpenJ9 JVMでの巨大なアプリケーションの起動でスタートアップ時間を削減するクラス共有と事前 (AOT) コンパイル戦略の利点が目立つ。記事からこのグラフを掲載する。

記事ではOpenJ9はロードがシステムに適用されたときでさえHotspotを使用したOpenJDKでのメモリフットプリントの半分しか使っておらず、パフォーマンスは同等のものを提供しているということにも言及している。クラウドやプラットフォーム・アズ・ア・サービス (PaaS) のデプロイは一般的に時間単位のメガバイト数で課金されるが、半分のメモリフットプリントで起動できれば特定のユースケースでは費用を相当削減できる可能性がある。