IBMがEclipse OMRを開発した。任意の言語用に実行環境を開発するための，オープンソースの仮想マシンツールキットだ。ガベージコレクションやハードウェア統合といった，どの言語にも共通する汎用的な仮想マシン技術の改善に寄与することを目的とする。これを達成するため，IBMは，自社のJVMであるJ9の汎用化を実施している。
JVMは多数の言語をサポートする汎用的な実行環境になりつつあるが，Java言語との関係が強いことから，その設計や機能の多くはJava自体と強く結び付いている。このため，JVMを他の言語のランタイムとして使用する場合，特に動的型付けの言語では問題を生じることになる - Java 7でInvokeDynamicが追加されるまで，動的言語は，JVMの静的型付けの性質を克服するための非効率的な回避策を強いられていたため，パフォーマンス面で大きな影響を受けていた。Daryl Maier氏を始めとするOMRプロジェクトのメンバが指摘しているように，言語開発者には２つの選択肢を与えられることになる。膨大なコストを費やして新たな言語用のランタイムを開発するか，制限を受け入れて既存の実行環境で動作するように適応するかのいずれかだ。
OMRは第３の選択肢を提供する。OMR自体はランタイムではなく，ランタイムを容易に開発するためのツールキットである。IBMのJava仮想マシンであるJ9からのコンポーネントをリファクタリングして開発されたOMRは，どの言語にも共通な機能の大部分を言語に依存しない形で実装すると同時に，開発チームが“ランゲージグルー(Language Glue)”と呼ぶ，OMRが提供する機能と開発中の言語とのブリッジとして動作する，言語固有のコードを開発するためのインターフェースセットを提供する。OMRとランゲージグルーの組み合わせによって，言語開発者は，次のようなランタイムを手に入れることができる。
- メモリアロケータ
- スレッドライブラリ
- ランタイムを異なるプラットフォームに移植するためのハードウェア抽象化層
- 別のランタイムやOSイベントに接続するためのイベントフックフレームワーク
- デバッグなどで使用するトレースエンジン
- ガーベジコレクション
- JITコンパイラ
採用を進めるために，ランゲージグルーのインターフェースは，最初から完全に実装する必要はなく，言語設計者が使用したいランタイム機能に応じて，その部分だけを実装すればよくなっている。例えば，シングルスレッドのマーク/スイープガベージコレクションを利用するには，単に3つのAPIを実装すればよいが，より多くを実装することで，コンカレントなマーキングや並列性，世代別ガベージコレクションなども利用できるようになる。
このリファクタリングによる影響で興味深いのは，個々のコンポーネントのテストが容易になっていることだ。変更前は，ガベージコレクションなどのコンポーネントを試験するにはランタイム全体を使用しなくてはならず，テストは複雑なセットアップと検証を数多く必要としていた。それが，この複雑なロジックを分割して切り離すことで，個々のパーツを独立してテストすることが可能になり，テストのセットアップと検証が簡素化されたのだ。
しかしながら，OMRで最も注目される特徴は，それがEclipse Foundation(戦略的メンバとしてIBMが参加している)を通じて運営されるオープンソースプロジェクトであるという事実だろう。プロジェクトリーダたちは，Eclipse Foundationが開発者コミュニティによるOMRへの革新的コントリビューションを促進し，その成果が，このツールキット上のランタイムを使用したすべての言語に活かされることを望んでいる。このことは，OMRがOpenJDKに対抗して，その勢力を拡大する上でも有効だろう。OpenJDKもオープンソースではあるのだが，GoogleによるCMSのパフォーマンス向上を例とするような有益なコントリビューションを取り込む上では，かねてからいくつもの問題に悩まされている。
このアプローチには，しかしながら欠点もある。言語設計者に既存のランタイム採用を強制することには，ある種の問題を抱える可能性もある一方で，異なる言語が同じ仮想マシン上で同時に動作可能になることから，言語の相互運用を可能にもしている。言語毎に異なるランタイムを開発するというOMRのアプローチでは，相互運用は不可能ではないにせよ，非常に難しいものになるはずだ。最終的には言語設計者が，相互運用性の容易性か，あるいは言語開発の容易性か，自身の戦略的な優先度に従っていずれかを選択することになるだろう。
この記事を評価
- 編集者評
- 編集長対応