レッドハットでのOpenJDKの未来

Java 11のリリースで、Javaの、OpenJDKを最優先にするプロジェクトへの移行が、ついに完了した。Javaのインストールのほとんどに、プロプライエタリなOracleJDKバイナリを使っていた日々は、終わったのだ。オープンで無償なJavaに対してさらに焦点を当てると、当然、オラクル以外の企業のコントリビューションがより顕著になる。InfoQは、Rich Sharples氏にインタビューをした。彼は、レッドハット所属で、ミドルウェアのプロダクトマネジメントをしているシニアディレクタである。インタビューでは、OpenJDKと、OpenJDKへのレッドハットの関わりについて、意見を交わしている。

InfoQ「レッドハットは、OpenJDKの。かなり初期からのコントリビュータです。プロジェクトにおける貴社の経歴について、話してもらえますか？」

Rich Sharples氏「レッドハットは、2007年11月5日に、サン・マイクロシステムズと、広範なコントリビュータ契約をして、それを発表しました。この契約は、レッドハットのエンジニアが、サンが主導するオープンソースプロジェクトすべてに参加することをカバーしていました。この一部として、レッドハットは、サンのOpenJDK Community TCKライセンス契約にサインしました。これを行った最初の主要なソフトウェアベンダとなりました。レッドハットは、サンと開発者のコントリビューションを共有することも表明しました。OpenJDKコミュニティを作り、イノベーションを発展させるためです。レッドハットは、オラクルの次に大きなOpenJDKのコントリビュータです。

こうすることで、レッドハットはJavaのエコシステムへの関与を深めてきました。その前年にJBossを買収しており、このことは意義深いものでした。2009年に、サンはオラクルに買収されましたが、サンとレッドハットで築いた関係性は、オラクルとなってからも続きました。

2007年にOpenJDKプロジェクトに参加して以来、レッドハットは、Red Hat Enterprise LinuxでのOpenJDKのパッケージングやサポートだけでなく、アップストリームのOpenJDKコミュニティにもコントリビュートを続けています。たとえば、レッドハットは2013年にOpenJDK 6のリーダーシップを引き受けました (そして2016年までそれをサポートしました)。2015年にはOpenJDK 7の管理を引き継ぎました。Andrew Haley氏は私たちの管理について、Red Hat Developer Blogでのこの投稿で説明しています。

OpenJDK 6は、Red Hat Enterprise Linux 5、6、7でパッケージし、サポートしました。OpenJDK 7も同様です。OpenJDK 8は、Red Hat Enterprise Linux 6と7でサポートしています。Red Hat Enterprise Linuxのさまざまなバージョンでのサポートの提供に加え、私たちのOpenJDKディストリビューションに対して、一貫してライフタイム・サポートを提供しています。

OpenJDK 7のライフサイクルは、2020年6月まで延長したところです。そして、OpenJDK 8のライフサイクルは、2023年6月まで延長しました。これは、OpenJDK 11への移行作業に対し十分な期間をユーザに提供したい、という意図です。

Red Hat Enterprise LinuxでのOpenJDKのディストリビュートとライフタイム・サポートの提供に加え、レッドハットのオープンソースのJavaミドルウェア製品は、Red Hat Enterprise LinuxのOpenJDKをサポートしており、これによりユーザは、オペレーティング・システムからアプリケーションサーバまでフルスタックのサポートを、単一ベンダから得られます。他のレッドハットの製品は、内部的にはOpenJDK上で動いています。私たちは、オープンソースに依存して生産的な作業を実行している世界中の顧客に対して、サポートを提供することにおいては、リーダなのです。」

InfoQ「現在の状況について、話しましょう。目下、レッドハットでOpenJDKに取り組んでいるエンジニアは何名なのでしょうか (フルタイムとパートタイム両方とも)？彼らはどの領域に取り組んでいるのでしょうか？」

Sharples氏「方針として、特定のプロジェクトでのレッドハットの投下資本は、公表していません。

レッドハットのJavaプラットフォームチームのリードエンジニア、Andrew HaleyはOpenJDKの運営委員会のメンバを長年務めており、AArch64ポートプロジェクトのリーダでもあります。加えて、AndrewはJDK 7プロジェクトのリーダでもあり、オラクルがOpenJDK 8と11をEOLにしたあと、それらのリーダに志願する予定です。」

InfoQ「特定の技術について話をしようと思います。レッドハットがもっともコントリビュートした領域はどこだと思われますか？レッドハットがもっとも強くリーダシップを取っている技術的なコンポーネントは何でしょうか？」

Sharples氏「レッドハットは、64ビットのARMv8のOpenJDK用ポート、AArch64を開始し、そのほとんどを書き、リードしています。そして、それをアップストリームのOpenJDKプロジェクトに移す手伝いをしました。現在、Shenandoahと呼ぶ、停止時間がとてつもなく短い新しいガベージコレクタに関して、OpenJDKコミュニティと協力しています。今はOpenJDKのメインラインの外にありますが、Red Hat Enterprise Linux 7では完全にサポートしています。OpenJDK 12でメインラインに入れることを目標に、作業しています。」

InfoQ氏「OpenJDKにおけるガベージコレクションの現在の状況は、大変興味深いものです。たとえば、JDK 11で、ついにG1がコレクタとして十分に成熟したものになりました。レッドハットにはShenandoahコレクタがありますが、オラクルもZGCに取り組んでいます。GC領域への参画における、レッドハットのアプローチについて、コメントしていただけませんか？とくに、G1についてお願いできますか？ShenandoahとZGCを、どのように比較して対比されますか？レッドハットは、いつShenandoahが本番環境で利用するコレクタとして妥当な選択肢となると考えているのか、予想してもらえませんか？」

Sharples氏「私たちが参画する主な領域は、今のところは今後もShenandoah GCのままです。加えて、とても大事な (ユーザからは見えませんが) コラボレーションが、HotspotのGCインタフェースの開発で起こっています。これが、レッドハットが積極的に参画しているところです。

GCコードは、以前はHotspotコードのいろいろな場所に散在していました。しかし、今はHotspotのコアも各GCも、他の全てのものから、とてもうまく分離されています。Shenandoahは、G1とコードをいくらか共有しているため、そこに改善とバグ修正がいくつか入ることにもなりました。とくに、G1は。もともとShenandoahで先に入った機能をいくつか取り入れています。たとえば、マルチスレッドでのフルGCや、直近ではアイドル時にヒープを確定させないことです。

ZGCとShenandoahは、目標がとても似ています (巨大ヒープでの停止時間を削減する)。しかし、両者の実装の戦略は、まったく異なります。Shenandoahはブルックスポインタを使い、ZGCは色付きポインタと多重メモリマッピングを使います。

ZGCは、スループットと停止時間に関しては、よりよい場合が多いです。しかし、Shenandoahはよりよいエルゴノミクスを持っています。これが意味することは、ヒープがほぼ一杯といったときやアロケーション爆発といったような難しい状況において、実用的によりうまく動作するということです。ZGCは、圧縮oopを (設計上) 使用できません。これは、中規模サイズ (<32GB) のヒープでは不利となります。その上、これは目標では決してありませんが、Shenandoahは小さなヒープでも、とてもうまく動作します。サイズが大きくなるかもしれないアプリケーションにとっては、Shenandoahが理想のGCとなりえますが、小さなヒープでの動作は保証していません。

Shenandoahは、RHEL >= 7.5のJDK-8uのディストリビューションの一部として、本番環境で利用する選択肢としてすでに提供されています。私たちの知る範囲では、本番環境ですでに使われています。私たちは現在、ShenandoahをJDK12のアップストリームに入れる作業に取り組んでいます。そうなれば、Shenandoahは実験的機能となるでしょう。アップストリームのOpenJDKディストリビューションで、その実験的フラグがいつ外れるかは、現時点で言えません。」

InfoQ「言うまでもなく、最近のビッグニュースの1つは、レッドハットが買収されるということです。これは、レッドハットがOpenJDKへ関与する際の立ち位置を変えてしまうのでしょうか？」

Sharples氏「IBMについて、さらに何かを言うことはできません。プレスリリースとJim Whitehurst氏のブログ投稿を参照してください。」

InfoQ「今OpenJDKで (そして広くJava / JVMエコシステムで)、もっともエキサイティングなところは、どこだと思われますか？今後12-18ヶ月、私たちの読者は、どの技術や新開発に対して、しっかりと注意を向けておくべきだと思われますか？」

Sharples氏「Javaは、大規模でビジネスに不可欠なアプリケーション向けのスケーラブルな言語ランタイムとして自分にとって最適であった領域を、超えていかなくてはなりません。そして、より軽量で機敏な言語やランタイムと、よりうまく競わなければなりません。とくに、メモリフットプリントやレイテンシにとても敏感な、クラウドネイティブな環境においてです。

気に留めておくべきエキサイティングなことは、JavaコミュニティがJVMレベルでイノベーションを続けていることです。とりわけ、GraalとSubstrate VMは、実行中のJVMの平均存続時間が、コンテナやdevops環境で著しく短くなることを理解したものです。モノリシックなアプリケーションは、一度の起動で数ヶ月間、JVM上で動作しました。継続的デリバリ環境でのコンテナ化されたマイクロサービスは、数日もしくは数時間だけしか動作しないかもしれません。サーバレスの世界では、(ミリ) 秒かもしれないのです。

注意しておくべき重要なことは、JVMが (再び) エキサイティングになったことだけでなく、より幅広いJavaのエコシステムがペースを維持していることに対してもです。JVM自身の最適化と、Thorntailのような新しく、軽量で、機敏なランタイムの継続的な導入とともに、今までモノリシックなアプリケーションを記述していたJava EE開発者を、軽量なマイクロサービスの世界に連れ出す手助けをする、Eclipse MicroProfileとその仕様、といったプロジェクトがあります。

レッドハットは、Fabic8 MavenプラグインやSpring Cloud Kubernetesといったツールで、KubernetesやIstio、OpenShiftに対してネイティブとなるJavaアプリケーションの開発手法を先導してきました。これは、マイクロサービスアーキテクチャを、大いにシンプルにします。ほんの数年前なら、このアーキテクチャには、個々に管理する必要がある多くのスタンドアロンのインフラストラクチャサービスが必要でした。Javaエコシステムは、全体として速いペースで前進し続けています。

また、エッジデバイスやゲートウェイ、モバイルデバイス、ウェアラブルといったクラウドアーキテクチャの新しい要素だけでなく、AIや機械学習といった特定の用途のための新しいチップのアーキテクチャ (ARMやGPUsなど) についても考えています。」

InfoQ「読者へ他にコメントはありますか？」

Sharples氏「Javaへの関心はかつてないほど大きくなっており、Javaの未来は、かつてないほど輝かしいものとなるでしょう。」