Microsoftは数ヶ月前、OpenJDKへのコントリビューションを改めて表明した。
コントリビューションの正確な内容が不明であったので、InfoQは今回、同社でJava担当プリンシパルグループSWEマネージャを務めるMartjin Verburg氏と、同じくプリンシパルプログラムマネージャのBruno Borges氏から、MicrosoftがOpenJDKに対して意図しているコントリビューションの詳細について聞くことにした。
両氏はOpenJDKへのコントリビューションに関する具体的な領域として、特にパフォーマンスやガベージコレクションを挙げる一方、コミュニティのニーズをベースとした柔軟なアプローチを維持するとも語った。特に、スタックアロケーションの"パッチ" -- メソッドローカルであることが分かっているオブジェクトをスタックに配置することによって、Javaプログラムのオブジェクトアロケーション率を自動的に低減することを目的とした一連のパッチについて、詳細な情報を提供してくれた。
InfoQ: クラウドネイティブなデプロイメントは、コンテナや多言語開発の方向にシフトしています。その前提において、Microsoftが先日発表したOpenJDKへのコントリビューションは、開発者やアーキテクトにとってどのような意味を持つのでしょうか？
Borges: 今日、世界中でJavaを使用している開発者やアーキテクトたちが、Javaのワークロードをクラウドネイティブなコンテナベースの環境に移行しようとしています。彼らがJavaベースのプログラミングモデル、Javaの持つ相互運用性といったメリットを引き続き享受したいと願うのは自然なことですし、自分たちチームの持つドメインや専門技術を活用したいと思うのは当然です。
Microsoftは現在、このようなユーザをAzure上で(Azure Kubernetes Service(AKS)、App Service、Big Data、Azure Spring Cloud、Funcrionなどを通じて)サポートしていますが、これらのサービスで基盤として使用されているOpenJDKランタイムを、特にクラウドネイティブなコンテナベース環境でのパフォーマンスに関して拡張することによって、エクスペリエンスを向上したいと考えています。
InfoQ: Java開発者やユーザ全体の利益のために、MicrosoftがJavaとOpenJDKにどのような投資を計画しているのか、概要を説明して頂けますか？
Verburg: OpenJDKのランタイムパフォーマンスを中心に、時間と専門技術を投入したいと考えています。コールドスタートアップに要する時間はその中のひとつですが、それだけではなく、ウォームスタートアップ時間やメモリプレッシャの低減(ガベージコレクションの低減とフットプリントの低減)、さまざまなGCアルゴリズムの改善、特定タイプのワークロードを対象としたJVMの自動コンフィギュレーションなども含んでいます。
ツーリングやテレメトリについても支援したいと考えています。Java Flight Recorderや関連機能については、すでに検討を開始しました。新たに提案されたJEP 349 Event Stream APIには、大きな可能性があると思います。
InfoQ: 現在のMicrosoftは、コントリビューションに関して非常に柔軟なアプローチを取っているように思われますが、もう少し具体的に、影響を与えたいと思っているOpenJDKの分野やタイムラインなどについて、コメントをお願いします。Microsoftのエンジニアは、すでにOpenJDKの開発に参加しているのでしょうか？
Verburg: はい、4,5個のパッチをすでにOpenJDKに提供しています。Javaの運営企業(Oracle)やおもなプレーヤ(RedHatやIBM)と緊密な関係の下で作業して、ユーザのニーズに応える最高のコラボレーションの方法を突き止めようとしています。
提供済みのパッチは次のようなものです。
- 8236179: C1 register allocation error with T_ADDRESS
- 8231863: Crash if classpath is read from @argument file and the main gets option argument
- 8234076: JVM crashes on Windows 10 using --module=NAME
Stack Allocation "パッチ"も開発中です。この一連のパッチは、メソッドローカルであると判明している(コンパイル用語では"非エスケープ(non-escaping)"な)オブジェクトのスタックアロケーションを行うことによって、Javaプログラムのオブジェクトアロケーション率を自動的に削減するためのもので、現在はさまざまな業界のベンチマークを通じてレグレッションのないことを確認すると同時に、Oracleやその他のOpenJDKベンダのエンジニアによる優れた提案を統合する作業を行っています。近いうちにJDK Enhancement Proposal(JEP)として立ち上げられると思います。
当面は小規模な修正やHotSpotの改善(ガベージコレクション、Just In Timeコンパイルなど)を中心としますが、OpenJDKや、さらに重要なものとしてコミュニティとの共同作業に関する経験を積んだ後には、もっと重要で影響の大きな機能に貢献したいと考えています。
InfoQ: Visual Studioは登場から何十年も経ちますが、開発者に広く愛用されています。MicrosoftがOpenJDKへのコントリビュートを通じて自社の開発ツールを強化する、ということについての関心はあるのでしょうか？
Borges: Microsoftが今、力を入れているのはVS Code用のJavaエクステンションです。マイクロサービスやクラウドネイティブなアプリケーションを開発しているJava開発者の間では非常にポピュラーな存在になっています。この方面への投資を、今後も続けていくつもりです。
InfoQ: GraalVMが最近、Javaコミュニティの間で注目を集め始めています。このVMはJava以外の言語もターゲットにしていますが、Microsoftとして、GraalVMとその意向に沿って、例えばC#などの新たな言語サポートの追加作業を行う予定はあるのでしょうか？
Verburg: 当社としては、Azureユーザの採用状況という点から、GraalVMはまだテクノロジおよびコミュニティの初期段階にあると理解していますが、注意深く見守っています。当社は昨年、最初に開催されたコミュニティワークショップに参加しています。先日も技術者のひとりがCGO 2020期間内のSan Diegoでのサミットに参加して、さまざまな気付きや学習結果を持ち帰ってくれました。すばらしい成果が上げられていますし、先日のアドバイザリボードに参加したコミュニティメンバの顔ぶれを見ても、プロジェクトが今後大きな注目を集めて、多くの採用を勝ち取ることは間違いありません。その時が来たならば、Oracleとともに開発に参加できるものと楽しみにしています。
InfoQ: OpenJDK(およびJavaエコシステム)の中で、InfoQの読者が特に注目すべき、エキサイティングなコンポーネントは何でしょうか？開発者一般、あるいはJava開発者に限定した場合はどうでしょう？
Verburg: ヴァルハラへの道(Road to Valhalla)もそうですが、バックグラウンドやオブジェクトモデルには特に関心があります。Java 14ではrecordが導入されます。これはビルディングブロックのひとつで、プログラミングの生産性改善に関する全カテゴリを解放すると同時に、いくつかの点でパフォーマンスを大幅に改善するものです。
結論としてMartijn Verjburg、Bruno Borges両氏は、パフォーマンとガベージコレクションの領域に特に重点を置くと同時に、コミュニティのニーズに基いて将来的に柔軟なアプローチを行う余地を残すという、MicrosoftのJDKへのコントリビューションの姿勢を概説している。