原文はこちら。
The original article was written by Claes Redestad (Principal Member of Technical Staff, Oracle).
https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html

JDK 16がまもなくrampdownフェーズに入ります。つまりフォークを作成し2021年3月のGAリリース前に安定化することを意味します。openjdk/jdkでの作業はまもなくJDK17以降を目指します。

openjdk/jdkリポジトリ
https://github.com/openjdk/jdk

まずはJDK16での起動時間のアップデートからはじめますが、今日気になっているのは、JDK17で何を目指すべきかということです。

Startup: Fixed?

JDK 9のいくつかのひどいリグレッションに促され、数年前から起動時間とフットプリントのリグレッションを見つけて修正する作業に携わってきました。以前にも、リグレッションのいくつかと、潮目を変えた多くの小さな改善点の詳細を報告しました。

OpenJDK Startup – Late 2019 Edition
https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html
https://logico-jp.io/2019/12/22/openjdk-startup-late-2019-edition/

作業は現在も継続しており、（開発サイクルの大半を育児休暇で過ごしてきたため）筆者のOpenJDK 16への貢献は微々たるものでしたが、たくさんの改善点をご紹介できる状態にあります。アプリケーションと構成次第ですが、Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz の環境での測定値では、JDK 11の前後でJDK 8に追いつき、徐々にその差を広げています。

換言すると、最小のHello Worldは私のラップトップではJDK 8で実行するのに45msほど要しましたが、JDK 16では25msほど要します。JDK 9では最も時間を要していておよそ85msほどだったので、およそ3.4倍の高速化です。

JDK 16: Module archiving

JDK 16の主な改善点は、デフォルトのCDSアーカイブにjavaモジュールが必要とするデータ構造の大部分をアーカイブすることにあります。

8244778: Archive full module graph in CDS
https://github.com/openjdk/jdk/commit/03a4df0acd103702e52dcd01c3f03fda4d7b04f5

完全なモジュールグラフをアーカイブ可能にするためには、複数のJDKとJVMエンジニアによる協調的な努力が必要でした。これを成し遂げるための英雄的な努力をしてくれたIoi LamとThomas Schatzlに感謝します。

ヒープデータをCDSアーカイブにアーカイブする作業はJDK 9で始まりました。その後のリリースでより複雑なものをアーカイブできるように段階的に増築してきました。しかし常にいくつかの幻覚にして禁止対象の実装上の制限があります。今年の2月のJFokusでこのトピックについてまぁまぁ技術的な話をしました（Covid-19以前、昔の話です）が、全てアーカイブすることの正味の効果は、正直言ってそれほど印象的なものではありませんでした。

Heap Archiving
http://cr.openjdk.java.net/~redestad/slides/heap_archiving.pdf

モジュールグラフをアーカイブできるようになったので、その効果はより大きなものになっています。GCサポートに関連したより強固なストーリーを持つことは、私たちがより自信を持って前進できることを意味します。

Going static

起動時のサイクルを奪うようなちょっとしたことをどんどんアーカイブしていくことも含めて、JVMをさらに高速に起動させるためにできることはたくさんあると思いますが、1ミリ秒の高速化ごとに努力のコストが増えるように思えます。何万ものクラスをロードするマイクロサービスをウォームアップするのに数秒かかるとしたら、JVMを5ミリ秒や10ミリ秒で起動させることはそれほど重要なことなのでしょうか？

しかし、最終的にJVMをProject Leydenの基礎として使用したいと思うかもしれません。このような状況では、競争力を維持するためには、すべての小さなミリ秒が重要になるかもしれません。

Call for Discussion: New Project: Leyden
https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html

Project LeydenはOpenJDKのスコープ内で静的イメージを実装、指定することを目的としています。静的イメージはつまるところ、閉世界仮説を前提としたjavaアプリケーションの最適化です。閉世界とは動的クラスローディングなどを許可しないということで、つまり利用されていないことがわかっているクラスやメソッド、フィールドの削除を含めて、他の方法に比べて積極的に最適化できるということです。

ゴールは、サイズや起動時間の点でネイティブ実行と遜色ないところに到達することであり、できれば特定のGCや監視ツール、その他のObsevabilityやツールの互換性といった機能のサポートを落とさずに実現することを目指しています。簡単でしょう？この分野での他の努力はすべて、いくつかの制限を持って終わるように見えます。十分に明確にされた静的（static）なjavaになる上で、これらの制限のうち、どの制限が実装が妥当であるか、を定義することがプロジェクトの目標になる可能性があります。

これをLeydenのパズルに配置するため、ヒープのアーカイブは驚くべきことに重要なピースになる可能性があります。単なる静的データのアーカイブというよりは、閉世界仮説を十分に活用し、JVMプロセスの状態の完全なスナップショットで終わらせることができるはずです。これだけでも、起動時間が相当速くなるかもしれません。

しかしながら、Leydenのようなプロジェクトでは説得力のあるものにするためにもうすこしピースが必要です。AOTコンパイルはそのようなピースになりそうです。Oracleとしては、実験的なAOTコンパイルツールのjaotcはもうだめかもしれませんが、C2を使うAOTコンパイルがそれを置き換える可能性があります。

8255616: Disable AOT and Graal in Oracle OpenJDK #960
https://github.com/openjdk/jdk/pull/960#issuecomment-722023038

たくさん再編成しなければなりませんね。私の役割がほんとよくわかりません。

See to something else entirely?

物事がさらに複雑になるので、Project Leydenまだ正式には始まっていませんが、その代わりに利用の可能性がある技術についてもっと学んでウォーミングアップしてきました。特にC2に没頭していました。

そう、古くて悪名高いけれども高度に最適化されている、多くのJavaエコシステムが依存しているJITコンパイラ、それがC2です。

さしあたっては、私はほとんどの場合、コードを整理しながらテストやマイクロベンチマークを追加して、物事がどのように動くのかを理解しようとしています。時には、少しずつ改善していくこともあるかもしれません。すでに、少数のクリーンアップと改善をJDK 16にプッシュすることに成功しています。

C2: Optimize copying of the shared type dictionary
https://bugs.openjdk.java.net/browse/JDK-8256274?jql=labels%20in%20(startup)%20and%20labels%20in%20(c2)

これまでの改善は控えめであり、これらの JIT コンパイルはバックグラウンドで行われているため、違いに気づく人はほとんどいないでしょう。そのため、重度の制約があるシステムや高負荷のシステムで多くのJVMを起動している場合を除き、C2への改善は、JVMの初期段階でCPUとメモリの使用量が一時的に急増するため、ほとんどの場合、気づくことができないでしょう。

ですが、運が良ければ（多くの作業が必要ですが）、静的化を試すことができる人や、喜んで試そうとする勇気のある多くの人のために、ウォームアップやパフォーマンスが出るようになるまでの時間が大きく減少する可能性があります。

C2をLeydenのAOTコンパイラとして使用することを考えるだけで、副作用として（Leydenがリリースされる前に）通常の JVM アプリのウォームアップをさらに向上させることになるかもしれません。このような相乗効果は非常にクールだと思います。それは、ほとんどの場合、こうした努力にきっと何らかの価値があります。OpenJDK のようなコアなものに対して努力し続けることが重要だと思います。

いずれにしても、現在C2を掘り下げて改善することに非常に楽しみを感じています。近いうちに、実際の最適化の実装にも手を出すかもしれません。筆者は本物のコンパイラエンジニアからは程遠いのですが、時間、経験、そして講読で何が起こるかは誰にも分かりません。

ご期待ください。そして最新のJDK リリースへアップグレードしてください。