OpenJDK：プロジェクトパナマ

2年前、コード名「Panama」という新しいプロジェクトがOpenJDKで作成されました。 研究の主な分野では、プラットフォームに依存するライブラリとJavaヒープ外（オフヒープ）のデータを操作するための新しいインターフェイスの作成が発表されました。 しかし、プロジェクトの目標はより広く、JVMと「外部」（非Java）API間の相互作用のメカニズムを研究することです。



ウラジミール・イワノフ iwanowwwはオラクルの主要エンジニアであり、HotSpot Java仮想マシン開発チームで働いています。 彼はJITのコンパイルとJavaプラットフォームでの代替言語のサポートを専門としています。 Vladimirは2005年にSun Microsystems（2010年にOracleに買収）に入社して以来、多数のJavaプロジェクト（HotSpot JVM、RTSJ、JavaFX）に参加しています。

JNI 2.0？

-パナマプロジェクトのほとんどは、Javaコードのネイティブライブラリを使用しています。 どうすれば今これを行うことができますか？



-Javaのネイティブコードを使用することは常に可能でした。 ネイティブメソッドはすでにJavaの最初のバージョンにあり、標準のJNIインターフェイスはバージョン1.1にすでにありました。 しかし、時間が経ち、プラットフォームが開発され、要件が変更され、現在JNIを見ると、ネイティブライブラリでの作業をより便利かつ効率的に整理できることが理解されています。



JNIには、使用の複雑さと速度に関連する多くの欠点があります。 ライブラリをアプリケーションに統合するには、C / C ++でライブラリのラッパーを記述するだけでなく、サポートされているすべてのプラットフォームにアセンブリを提供する必要があります。 これは、最新のJavaアプリケーションのコンパイルプロセスにうまく適合せず、実装の大きな障壁になる可能性があります。 また、Java中心であるため、JNIを介した各呼び出しには特定のオーバーヘッドが伴います。これは、小さなメソッドでも集中的に作業する場合に特に顕著になります。 パナマプロジェクトは、とりわけ、より便利で生産的なJNIの新しいバージョンである「JNI 2.0」を作成する試みです。 そして、すでにJEPがあります： JEP 191： "Foreign Function Interface" 。



-JNIは非常に複雑に設計されているため、使用するのは快適ではないという意見があります。 これについてどう思いますか？



-これは「都市伝説」のカテゴリーのものです。 全体として、意見はもちろん間違っていますが、それにはいくらかの真実があります。JNIの改善に投資することは優先事項ではありませんでした。 すべてをJavaで記述する方がより効率的で便利であると信じられていました。 ユーザーニーズの90％以上をカバーするインターフェイスがあり、開発する必要はありませんでした。 また、サードパーティのライブラリを使用すると、JNIでの作業を大幅に簡素化できます。 JNRをご覧ください。これにより、C / C ++コードを記述せずに、ネイティブライブラリを完全に操作できます。



-JNIはすでに20歳ですが、なぜパナマプロジェクトが登場し、今開発中ですか？



-私たちはこのプロジェクトに熟していると言えます。 長年にわたって、JNIの長所と短所が明らかになり、Javaプラットフォームはその開発において長い道のりを歩んできました。 Javaだけでアプリケーションを開発することが常に推奨されるとは限らないことが明らかになりました。さらに、Javaヒープ外のデータを扱うことがはるかに一般的になっています。 JNIとNIOはすべてのニーズを満たしていないため、ユーザーはsun.misc.Unsafeを使用する必要があります。 パナマプロジェクトは、彼らが直面する多くの問題を解決することを目指しています。



プロジェクトを監督するJohn Rose（OracleアーキテクトJVM JVM）が発表したように、有用なライブラリは、Javaエコシステムの一部として（Javaで書かれているかどうかに関係なく）簡単にアクセスできる必要があります。



たとえば、元々Fortranで書かれた線形代数パッケージLAPACKがあります。 多くのリソースが最適化に投資されており、Javaでの書き直しは何の役にも立たないでしょう。 たとえば、C / C ++プログラマが行うように、単純に再利用する方がはるかに生産的です。



一般に、「外を見る」最初の試みはProject Sumatraと考えることができます。その目的は、GPUを使用してJavaプログラムを実行するための見通しを研究することでした。 理論的には、すべてが非常に魅力的に聞こえます。GPUが利用可能なデバイスでプログラムを実行すると、JVMが自動的に使用を開始します。 しかし実際には、すべてがそれほどバラ色ではなく、最新のGPUでJavaバイトコードを実行するための効果的なメカニズムを作成できませんでした。 JavaからGPUを操作するためのJavaライブラリ（ AparapiおよびRootbeer ）がいくつかありますが、OpenCL / CUDAに似たかなり低レベルのアプローチを提供します。



パナマでは、GPUの使用に関する問題について異なる視点があります。GPUでJavaバイトコードを実行する必要はありません。GPUで何をすべきかを知っているライブラリを操作するだけで十分です。 このような機能は、たとえば、一部のBLAS実装とMAGMA線形代数パッケージに備わっています。



-プログラマーは現在、JNIを使​​用してどのようなタスクを解決していますか？



-Javaライブラリのエコシステムは豊富ですが、すべてがJavaで書かれているわけではありません。 線形代数とLAPACKパッケージについては既に述べました。 Javaプログラムでそれらを使用する唯一の方法はJNIです。 別の例は3Dグラフィックスです。JavaからOpenGLを操作する方法は？ 標準のJava APIはなく、必要な機能を備えたプラットフォーム実装がありますが、Javaからそれらと統合する方法が必要です。 答えはやはりJNIです。



-そして、どのような成功したプロジェクトが現在JNIを使​​用していますか？



-一般的に、多かれ少なかれ人気のある非JavaライブラリにはJavaのラッパーバージョンがあります。もちろん、これはすべてJNIを使​​用して実装されます。 たとえば、コンピュータービジョンの分野では、これはOpenCVライブラリです。 3Dグラフィックスを見ると、これはOpenGL APIとLightweight Java Game LibraryのJavaバインディングです 。



線形代数パッケージに関して、 netlib-javaはBLAS / LAPACKプラットフォーム実装へのアクセスを提供します。 ところで、 Apache Sparkの最新バージョンに存在します。



Javaプロジェクトからは、JNIが直接使用するのではなく、プラットフォーム固有のAPIを操作するためにJNRに依存するJRubyに言及します。

ヒープ外アクセスとデータ操作

-ネイティブライブラリを呼び出すためのインターフェイスに加えて、パナマプロジェクトにはネイティブデータ構造のサポートが含まれています。 それを別の機能と考えていますか、それともネイティブライブラリを呼び出すために必要な機能と考えていますか？



-それと別の両方。 Javaのネイティブコードを扱う際の主な問題は、データ交換です。 仮想マシンはJavaオブジェクトの表現を完全に自由に選択でき、多くの場合、この形式はネイティブライブラリと一貫性がありません。 データを前後にコピーするか、1つのコピーで作業する必要があります。



JNIは、ネイティブコードでJavaヒープにアクセスするためのAPIを提供し、オフヒープで作業するには、JNIラッパーでコードを記述する必要があります。 パフォーマンスと必要なコードの量の両方の点で非常に高価です。



パナマでは、新しいフォーマット（ Layout Definition Language ）に取り組んでいます。これにより、かなり複雑なデータ構造をコンパクトで柔軟な形式で記述することができます。 LDL記述はC / C ++ヘッダーから自動的に抽出でき、データを処理するためのJavaコードは「オンザフライ」の記述に従って生成されます。 JVMは、この情報を使用して、たとえば、GC内のJavaオブジェクトへのポインターを検索することもできます。 この場合、ネイティブコードは、追加の適応なしで、このデータを直接操作できます。



ポインターと明示的なメモリ管理との組み合わせで、これはオフヒープソリューションに使用されるsun.misc.Unsafe機能の一部を完全にカバーします。



しかし、それだけではありません。 JVM側の適切なサポートにより、LDLを使用してJavaオブジェクトの構造を記述することができます。



まず第一に、これにより整列を制御し、パディングフィールドを作成できます。

「ホット」コードでは、偽共有と非境界整列メモリアクセスの影響が実行速度に深刻な影響を及ぼします。 JDK内には@Contendedアノテーションがありますが、ユーザーにとって、誤った共有を回避する唯一の方法は、JVMが順序を維持することを期待して、問題のフィールドを他のフィールドと手動で「オーバーレイ」することです。



しかし、最も重要なことは、融合線（見出しと1つのオブジェクトとしての文字の配列）やタグ付き配列（配列の各要素またはプリミティブ値、またはオブジェクトへのポインター）など、多くのエキゾチックな構造への道を開きます。



プロジェクトのこの部分には、データへの高速アクセス（任意およびシーケンシャルの両方）を備えたコンパクトなJava構造を作成するという点で、Valhallaおよび値型と共通点があります。



-プロジェクトの機能はユーザーから最も需要があると思いますか？



-パナマには多くの独立した研究分野があります。 1つ目は、ネイティブコードとオフヒープデータの操作です。 これが、新しいJNI置換APIの出番です。 私の推定によると、プロジェクトのこの部分は最も人気があるはずです。



他の方向から、データのバッチ処理用のAPI（ Vector API ）に言及します。 最新のプロセッサには、データのバッチ処理用の命令 （ SIMD命令 ）を含むベクトル拡張（x86ではSSEとAVX、ARMではNEON）があります。 現時点では、JVMは動的コンパイル中にコードの自動ベクトル化を実行できますが、これはすべての興味深いケースをカバーしているわけではありません。 データのバッチ処理の操作を明示的に記述することを可能にする特別なAPIの作業が進行中です。



もう1つの分野は、Arrays 2.0とも呼ばれるJava配列の更新です。 配列は最初からJavaにあり、いくつかの面では非常に時代遅れです（たとえば、2Gbのサイズ制限）。 それらを記述して操作するための、より効果的で柔軟なメカニズムが必要です。



-JVMおよびJavaのその他の変更と比較した場合、現時点でのパナマプロジェクトの重要性は？



-パナマでの作業は積極的に進行中ですが、まだ研究段階です。 Javaに何をいつ統合するかはまだ決めていません。



これまで、JDK 9の重要なプロジェクトはプラットフォームのモジュール化です（ Project Jigsaw ）。



パナマの文脈では、 VarHandleの外観は非常に興味深いものです（ JEP 193：“ Variable Handles” ）。 これらは、フィールドと配列の両方、およびオフヒープデータの両方で機能し、標準のJavaメモリモデルでは説明できない多くの特殊な読み取り/書き込みモードを提供します。 このようなサポートは、非ブロッキング同期の効果的な実装に必要です。java.util.concurrentパッケージは、JDK 9のsun.misc.UnsafeからVarHandleにすでに完全に移行されています。 パナマで提案された新しいプリミティブは、 VarHandleを介してアクセスパラダイムに適合し、オンヒープデータとオフヒープデータへのアクセスを統一する必要があります。

次は？ JDKの未来

-そして、将来のバージョンでは？



-現在も活発に開発されているのがプロジェクトヴァルハラです。 パナマプロジェクトは耳には聞こえませんが、私の意見では、長期的にはJavaプラットフォームにとってそれほど重要ではありません。



FFIの話とオフヒープの操作はかなり前から続いていますが、最近ではVector APIに強い関心が寄せられています。 今年のJVM Language Summitカンファレンスでは、面白い瞬間がありました。パナマについて議論するとき、Facebookの同僚は、 Vector APIがJavaに登場するのをいつ待つかについて非常に興味があり、3年前に本当に必要だと言いました。 彼らが長い間沈黙していたのは残念です。 彼らは毎年JVMLSに来ているので、トピックをすぐに提起する必要がありました。 当時、明示的なベクトル化のサポートにはあまり関心がありませんでした。



-Javaで記述された一部のプロジェクトは、新しいAPIを使用して書き換えられる予定ですか？



-もちろん、JNIは残りますが、現在JNIを使​​用している人々にとって、新しいAPIははるかに魅力的です。 新しいインターフェースを備えた私たちの経験から判断すると、JNIの必要性はもはやないはずです。



現在のプロトタイプを積極的に実験しており、その結果に満足しています。Clangは C / C ++ヘッダーから情報を抽出するために使用され、今では「バインディング」全体がパナマの新しいツールキットによって作成されます。 シンプルで便利なため、移行中の時間を大幅に節約できます。



-つまり、パナマプロジェクトはJavaプラットフォーム内で需要がありますか？



-もちろん、ネイティブコードの呼び出しもプラットフォーム内で積極的に使用されるため、より便利で効率的なメカニズムの出現により、JDKで徐々に切り替えますが、パナマは内部として位置付けられていません。 その目標は、Javaプラットフォームのネイティブコードとオフヒープデータを操作するための新しいメカニズムを作成することです。これは、新しいパブリックAPIの出現を意味します。



-つまり、JNIはレガシーフレームワークとしての言語のままですか？



-誰もまだJNIを取り除くつもりはありません。 下位互換性はJavaにとって重要であり、サポートは継続されます。 将来、JNIが「削除用」とマークされる可能性があります（廃止予定）が、現時点ではそのような計画はありません。



また、JNIはパナマプロジェクトでの作業から利益を得る可能性が最も高いことに注意したいと思います。 ネイティブコードを効果的に使用するには、JVM側での本格的なサポートが必要です。 したがって、新しいJVMプリミティブを使用してJNIを書き換えると、パフォーマンスが大幅に向上します。



- そして、JDK 9では他に何が利用可能になりますか？



-あまり知られていないプロジェクトのうち、JVMCIインターフェース（ JEP 243：“ Java-Level JVM Compiler Interface” ）を選びます。 これを使用すると、サードパーティのダイナミックコンパイラをJVMに接続できます。このAPIの最初のユーザーは、Oracle Labsが開発したGraalです。 これは、すべてJavaで記述された新しいJITコンパイラです。



-つまり、標準のJITコンパイラをGraalに置き換えることは可能でしょうか？



-はい、Graalは、最適化されたコードを生成する「ラストレベル」コンパイラー（ホットスポットのC2サーバーコンパイラーを置き換える）として、または仮想マシンの唯一のJITコンパイラーとして使用できます。 現在入手可能ですが、特別なJVMビルドが必要です。



一般に、「Java on Java」実装の実験は長い間行われてきました。 Maxine VMのプロジェクトがありました。完全に（！）Javaで書かれた仮想マシンです。 最大の成功は、動的コンパイラの分野で達成されました。 結局のところ、GraalはクライアントコンパイラをHotSpotからJavaに書き直す試みから始まりました。 Maxineでは、最初はC1Xと呼ばれていました。 最後に、プラットフォームで開発を実装するときが来ました。



JVMエンジニアとして、Javaで仮想マシンを書き換える傾向は非常に印象的です。 一方では、便利なツールキット、高レベルの言語構成、マルチスレッドプログラミングの優れたサポートを備えた広範な標準ライブラリがある最新のプラットフォームで実装を取得します。 また、このプラットフォームを完全に制御することも重要です。そのため、必要な方向にプラットフォームを拡張し、自分で発生する問題を解決する機会があります。 一方、低レベルのタスクを解決するためのJavaツールを追加します。 そして、パナマプロジェクトはこれで重要な役割の1つを果たします。

---

私たちと同じくらいJVMの「ガッツ」が好きな場合は、 Vladimirのレポート「ネイティブコード、オフヒープデータ、Java」に加えて 、次のJoker 2016レポートをご覧になることをお勧めします。

• Javaからアセンブリーへ：ウサギの穴
• JITコードのライフサイクル
• Elbrus上のJava
• HotSpot Internals：セーフポイント、NullPointers、およびStackOverflow