JDK 13のShenandoah GC パート3:アーキテクチャとオペレーティングシステム

Red Hat で Solution Architect として OpenJDK を担当している伊藤ちひろ(@chiroito)です。

この記事は、Red Hat Developerのブログ記事、Shenandoah GC in JDK 13, Part 3: Architectures and operating systems | Red Hat Developer の翻訳記事です。


https://developers.redhat.com/sites/default/files/styles/article_feature/public/blog/2019/06/shenandoah-solaris-unsplash.jpg?itok=Q5xpy5Ve

このシリーズでは、JDK 13で登場するShenandoah GCの新展開を取り上げてきました。パート1では、ロードリファレンスバリアに変更されたことを見て、パート2では、オブジェクトごとに余分なワードをなくす計画を見てきました。今回は、Shenandoah GCが扱うことになる新しいアーキテクチャと新しいOSについて見ていきます。

Solaris

BellSoft最近変更を加えました 。これにより、ShenandoahはSolaris上でビルド・実行できるようになりました。Shenandoah自体には、オペレーティングシステム固有のコードはありません。したがって、新しいオペレーティングシステムへの移植は比較的簡単です。今回のケースでは、Solarisコンパイラを満足させるために、列挙型の末尾のカンマを削除するなど、一連の修正を行っただけです。

特に問題となったのは、Solaris 10です。Solaris 10は、Solarisの後続バージョンや他のすべての関連オペレーティングシステムが行っているのとは逆に、ユーザーメモリを上位のアドレス範囲にマッピングします(たとえば、0x7fではなく0xff...で始まるアドレス)。他のOSでは、アドレス空間の上半分をカーネルメモリに割り当てています。

このアプローチは、Shenandoahのタスクキューの最適化と相反するものでした。これは、上位アドレス範囲に予備のスペースがあると仮定してポインタをエンコードします。これはビルド時のフラグで無効にするのに十分なほど簡単で、Aleksey Shipilevがそれを行いましたその修正は、Shenandoah GCの完全に内部的なものであり、ヒープ内のJava参照の表現には影響しません。この変更により、ShenandoahはSolaris 10以降でビルド・実行できるようになりました(もっと古い可能性もありますが、試していません)。これは、Solaris上でShenandoahを走らせたい人たちにとって興味深いだけでなく、私たちにとっても興味深いことです。なぜなら、非メインラインのツール群を満足させるためには、余分なクリーンさが必要だからです。

Solarisサポートのための変更点は、すでにJDK 13の開発用リポジトリに含まれており、ShenandoahのJDK 11およびJDK 8のバックポート用リポジトリにもバックポートされています。

x86_32

Shenandoahはずいぶん前に"passive"モードでx86_32をサポートしていました。このモードでは、バリアの実装を避けるためにstop-the-world GCのみに依存します(基本的には、Degenerated GCを常に実行します)。このモードは、本当に小さなマイクロサービスサイズのVMで、アンコミットとスリムなネイティブポインタで得られるフットプリントの数値を見るのに興味深いモードでした。このモードはアップストリームに統合する前に削除されました。なぜなら、多くのShenandoahのテストは、すべてのヒューリスティック/モードが適切に動作することを期待しており、初歩的なx86_32サポートがあると、Tier1テストを壊してしまうからです。 そのため、これを無効にしました。

今日では、ロードリファレンスバリア個別の転送ポインタスロットの排除のおかげで、ランタイムインターフェースが大幅に簡素化されました。そして、その上に完全にコンカレントなx86_32を構築できます。このアプローチにより、Shenandoahのコードで32ビットのクリーンさを維持することができます(この変更の前に5つ以上のバグを修正しました!)。また、Shenandoahが32ビットプラットフォームで実装できるという概念の証明にもなります。 これは、コンテナや組み込みシステムなど、余分なフットプリントの削減が重要なシナリオで興味深いものです。 LRB + 転送ポインタしない + 32-bitサポートの組み合わせにより、現在のフットプリントの最低限度を実現しています。これは、Shenandoahでも可能でしょう。

x86_32ビットサポートのための変更は完了しており、JDK 13に統合する準備ができています。しかし、現在は転送ポインタの変更の排除を待っており、それに伴いC2の厄介なバグフィックスを待っています。計画では、ロードリファレンスバリアと転送ポインタの廃止の変更がバックポートされた後、後にShenandoah JDK 11とJDK 8のバックポートにバックポートする予定です。

その他のアーキテクチャやOS

OSとアーキテクチャのサポートにこの2つが追加されたことで、Shenandoahはまもなく4つのOSで利用できるようになります(例えば、ビルドして実行できることがわかっている)。 Linux、Windows、MacOS、Solarisの4つのOSと、x86_64、arm64、x86_32の3つのアーキテクチャに対応します。これは、OS固有のコードを一切使用せず、過度に複雑なアーキテクチャ固有のコードも使用しないというShenandoahの設計によるものです。将来のリリースでは、より多くのOSやアーキテクチャを仲間に加えることを検討するかもしれません(誰かが実装するほど面白いと思えば)。

いつものように、リリースを待ちたくない方は、すでにすべてを手に入れ、問題の解決に協力することができます:Shenandoah GC Wikiをチェックしてみてください。

もっと読む

JDK 13のShenandoah GC パート1:ロードリファレンスバリア

JDK 13のShenandoah GC パート2:転送ポインタワードの廃止

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。