Loading article…
Eclipse OpenJ9 （元々はIBM J9として公開）は、 Java仮想マシン仕様に完全に準拠した、高性能でスケーラブルなJava仮想マシン（JVM）実装です。 [ 3 ]
OpenJ9 はソースからビルドすることも、Linux、Windows [ 4 ]、macOSなど多数のプラットフォーム向けにIBM Semeru Runtimesプロジェクトで入手可能なビルド済みバイナリを使用することもできます。OpenJ9 は IBM 開発者キットの中核コンポーネントでもあり、WebSphere Application ServerやWebsphere Libertyなど多くの IBM ミドルウェア製品に組み込まれています。OpenJ9 は Open Liberty のコンポーネントでもあります。[ 5 ]
豊富な設定オプションにより、JVMは、メインフレームハードウェア上で動作する複雑なエンタープライズアプリケーションから、コンテナベースのクラウドサービス上で動作する短命なアプリケーションまで、幅広いJavaアプリケーションの要件を満たすように調整できます。
OpenJ9 は、Object Technology International (OTI)が開発した ENVY/Smalltalk 製品にルーツがあります。IBMは、Smalltalk の専門知識と製品を求めて 1996 年に OTI を買収しました。しかし、Java 言語がエンタープライズ市場の主要言語として台頭すると、既存の Smalltalk VM は代わりに Java バイトコードを処理するように変更されました。J9 という名前は、Smalltalkソースコードの命名規則K8から派生しました。K →J (後退) は、開発者が Smalltalk は Java より優れていると考えていたため、8→9 (前進) は、新しい VM が以前よりも優れていると考えていたためです。[ 6 ]
J9 JVMは、IBMの多くのエンタープライズミドルウェア製品のランタイムエンジンとなり、そこで高性能、拡張性、信頼性において高い評価を確立しました。
2017年、J9はEclipse Foundationのプロジェクトとなり、 Eclipse OpenJ9という名称になりました。IBMは引き続きこのプロジェクトに積極的に関与し、このJava VMを多くのソフトウェア製品の中核に据えています。Eclipse Foundationでは、OpenJ9はインキュベータープロジェクトとして位置づけられており、最初のリリースであるv0.8.0は2018年に公開されました。
Eclipse OpenJ9 JVM は、Java JVM 仕様に完全に準拠しています。同じバージョンの JVM は OpenJDK 8 以降のリリースで使用できるため、異なるバージョンの Java で実行されるアプリケーションでも多くの機能や改善点を活用できます。OpenJDK HotSpot VM と比較すると、 OpenJ9 は起動パフォーマンスが高く、メモリ消費量が少なく、全体的なスループットは同程度です。[ 7 ]
Eclipse OpenJ9 にはEclipse OMRが組み込まれており、さまざまなプログラミング言語のランタイム環境を構築するために使用できるコアランタイムコンポーネントを提供します。OpenJ9 プロジェクトでは、追加のコードレイヤーによって言語のセマンティクスが追加され、Java アプリケーション用のランタイム環境が提供されます。[ 8 ]
Eclipse OpenJ9を構成する各コンポーネントについては、以下のセクションで説明します。
Just -In-Time (JIT) は、実行時にプラットフォームに依存しない Java バイトコードをネイティブマシンコードにコンパイルすることで、Java アプリケーションのパフォーマンスを向上させます。アプリケーションから呼び出されるすべてのメソッドがコンパイルされるわけではありません。代わりに、OpenJ9 はメソッドの呼び出し回数を記録し、事前に定義されたしきい値に達すると JIT コンパイルをトリガーします。JIT コンパイラは、メソッドを「コールド」 、「ウォーム」、 「ホット」、「ベリーホット (プロファイリングあり)」、 「スコーチング」の 4 つの最適化レベルでコンパイルします。最適化レベルが高いほど、期待されるパフォーマンスは向上しますが、CPU とメモリのコストも高くなります。最適化レベルが高いほど、エスケープ解析や部分的な冗長性除去などの特殊な手法を使用したり、特定の最適化シーケンスをより多く実行したりします。これらの手法はコンパイル中の CPU とメモリの要求を増加させますが、生成されたコードのパフォーマンスが向上するため、「ホット」コードの場合はそのトレードオフに見合う価値があります。
AOT（ Ahead of Time）コンパイルは、起動パフォーマンスを向上させるためのメカニズムです。メソッドは実行時に動的にAOTコードにコンパイルされるため、JVMはアプリケーションをより高速に起動できます。AOTは、クラスデータ共有（-Xshareclasses）が使用されている場合に自動的に有効になり、特別な調整は必要ありません。OpenJ9は、大規模アプリケーションの起動フェーズを識別するヒューリスティックに基づいて、コンパイルするメソッドを自動的に選択します。小規模または実行時間の短いアプリケーションの場合は、 AOTコンパイルされたコードを最大限に活用するために、 -Xtune:virtualizedオプションを追加する必要があります。
JVM間でクラスデータを共有することには、主に2つの利点があります。
他のクラスデータ共有 (CDS) 実装とは異なり、OpenJ9 でこの機能を有効にするには、アプリケーションの起動時にコマンドラインで-Xshareclasses を設定するという 1 つの手順だけで済みます。指定すると、OpenJ9 はメモリマップドファイルを作成し、メモリ内のクラスを保存して共有します。デフォルトでは、OpenJ9 はデフォルトのシステムクラスローダーによってロードされるブートストラップクラスとアプリケーションクラスの両方を常に共有します。OpenJ9 CDS 実装のもう 1 つの利点は、キャッシュが動的に更新されることです。そのため、アプリケーションが新しいクラスをロードすると、JVM はユーザーの介入なしに自動的にそれらをキャッシュに保存します。[ 9 ]
OpenJ9は、カスタムクラスローダーにクラス共有サポートを統合するための公開ヘルパーAPIに加え、アクティブキャッシュを管理するためのいくつかのユーティリティも提供しています。
アプリケーションがメモリ不足にならないようにするには、Java ヒープ内の不要になったオブジェクトを解放する必要があります。このプロセスはガベージ コレクション(GC) と呼ばれます。OpenJ9 は、さまざまな種類のアプリケーションとワークロードに合わせて設計された、複数のガベージ コレクション ポリシーを提供します。適切なポリシーの選択は、使用状況とパフォーマンスの目標によって異なります。デフォルトでは、OpenJ9 は世代別同時実行 ( -Xgcpolicy:gencon) ポリシーを使用します。これは、短命なオブジェクトを多数持つトランザクション アプリケーションに最適です。代替ポリシーも利用可能で、Java ヒープが大きいアプリケーション ( -Xgcpolicy:balanced)、応答時間に敏感なアプリケーション ( -Xgcpolicy:metronome)、高いアプリケーション スループットを必要とするアプリケーション ( -Xgcpolicy:optthruput) に対応するポリシーなどがあります。
「アイドルチューニング」オプション（-XX:+IdleTuningGcOnIdle）は、アプリケーションがアイドル状態のときに OpenJ9 でガベージコレクションをトリガーします。これによりメモリ使用量が削減され、一部の仮想ホスティング料金プランにとって意味があります。[ 7 ]
2020年1月、OpenJ9はJVMの外部、つまりサーバー上でリモートでコードをJITコンパイルする実験的な機能を提供しました。
OpenJ9には、実行時の問題を特定、分離、解決するのに役立つ豊富なトレースおよびデバッグユーティリティが含まれています。特定のイベントが発生すると、さまざまな種類の診断データがデフォルトで自動的に生成されますが、コマンドラインからトリガーすることもできます。データの種類には以下が含まれます。
The diagnostic component also includes the DTFJ application programming interface, which can be used to build diagnostic tools. DTFJ works with data from a system dump or a Java dump.
