Project Leyden がもたらした新しい視点

Netty のケースは、インターフェースの実装の機能を判断するためにアノテーションを読み込んでいるため、特に興味深いものです。

このようなユースケースには、アノテーションの代わりにマーカーインターフェースまたはメソッドを使用することをお勧めします。

Georgios は再びバイトコードの書き換えを利用して、アノテーションのルックアップを排除しました。これもまた、長期的にメンテナンスしたいものではありません。

Hibernate ORM もこの文脈において非常に興味深いものです。

最初の重要な点は、Quarkus における Hibernate ORM では、依然として実行時にメタデータを構築しているということです。つまり、実行時に多くのアノテーションを読み込むことになります。この状況を改善するための長期的な取り組みはすでに始まっていますが、これは大規模なプロジェクトであり、メタデータの構築をビルド時に移行できるようになるまでには時間がかかります。

それはひとまず置いておきましょう。

また興味深いのは、Hibernate ORM が実行時に、Hibernate 独自のアノテーションと JPA アノテーションの両方について、自身のメタデータを収集している点です。これは膨大な量のアノテーションであり、処理すべきメタデータも大量にあります。

たとえば、JPA または Hibernate の各アノテーションに対して、アノテーションのターゲット (クラス、メソッド、フィールド) や、それが継承されているかどうかを判断します。

結局のところ、めったに変更されないものに対して、かなりの量のアノテーション処理が行われていることになります。

私は少し前にこの問題を特定し、Hibernate チームの同僚である Luca Molteni が近いうちに調査する予定です。修正がどれほど容易かはまだわかりませんが、要旨は理解していただけるでしょう。可能な限り、この種のメタデータは一度だけで完全に解決されるべきです。そして、テストによってその正確さを強制し、正確で最新の状態を維持できるようにすべきです。

近いうちにこれを改善できることを願っています。そして、ここでの改善は Quarkus アプリケーションだけでなく、Hibernate ORM を使用するすべてのアプリケーションに利益をもたらすという点が素晴らしいところです。

なぜ存在しないクラスをロードしようとするのでしょうか？それは良い質問です。

package-info.java ファイルを覚えていますか？たとえば Hibernate ORM は、パッケージレベルのアノテーションを検査するためにこれらをロードしようとします。多くの場合、これらのファイルは存在しませんが、それは完全に正常なことです。

クラスロードのキャッシュは Leyden のスコープ内ですが、Leyden はネガティブキャッシュ (存在しないことのキャッシュ) は行いません。なぜでしょうか？Leyden は AOT (事前コンパイル) ですが、依然として真の Java だからです。Java は動的な言語です。キャッシュを記録したときにクラスが存在しなかったとしても、後で追加されるかもしれません。実際には、特に「閉じた世界 (closed world)」を前提とする Quarkus ではそうではないことが多いのですが、Leyden はその前提に頼ることはできません。

Quarkus で Leyden を使用する場合、エンティティを含むすべてのパッケージに対して、まだ存在しない場合に空の package-info クラスを生成することにしました。これにより、Hibernate ORM は存在しないクラスをロードしようとする必要がなくなります。

別の例は JBoss Logging の国際化です。現在のロケールのクラスをロードしようとし、そのクラスが存在しない場合はデフォルトのクラスにフォールバックします。

リソースでも同様のパターンが見られます。アプリケーションが存在しない設定ファイルやサービス記述子をロードしようとすることがあります。それは完全に正常であり、欠落していることを知る唯一の方法は試してみることです。

Quarkus では、これを軽減するためのクラスローダーのトリックをいくつか持っています。しかし、一般的なケースでは、それに対処する必要があります。

ここに落とし穴があります。これらすべてのケースで、ランタイムはクラスパス全体を走査し (何も見つからないことを思い出してください)、クラスやリソースを特定しようとします。その際、クラスやリソースが存在しないという結論を出すためだけに、大量の JAR ファイルを開いて読み取る可能性があります。

確かに JAR 全体を読み取るわけではなく、各アーカイブにはインデックスがありますが、それでもコストはかかります。

ServiceLoader のケースを詳しく見てみましょう。これは特に興味深いものです。

クラスロードが問題にならなくなると、起動時間のかなりの部分が JAR ファイルからのサービス記述子のロードに費やされていることが明らかになります。私たちはクラスローダーのトリックを使って一部のサービスでこれを改善できましたが、それはスレッドコンテキストクラスローダーを通じてロードされるサービスに対してのみ有効です。JDK クラスローダーによってロードされるサービスについては、まだ良い解決策がありません。少なくとも今のところは。

次回のブログ投稿では、Project Leyden 自体と、それをどのように Quarkus に統合したかについて詳しく説明します。お楽しみに。

これは単純明快です。 UUID を生成するたびに、JDK は SecureRandom インスタンスを初期化します。そして、 SecureRandom インスタンスの初期化は、決してタダではありません。

もちろん、アプリケーションがいずれにせよ SecureRandom を必要とするのであれば気にすることはありません。しかし、必要ない場合に、お気に入りのフレームワークが内部用途のために UUID を生成するのは理想的ではありません。

同様に、 BigDecimal クラスには、実際にはかなりの量の作業を行う静的初期化子があります。 BigDecimal の初期化には、無視できない時間がかかることがあります。

私たちがこれに遭遇したのは、Quarkus の起動時間を出力する際にいくつかの計算を行うために BigDecimal を使用していたからです。

なんてことだ。

そのコードを置き換えましたが、別の問題が見つかりました。 Hibernate ORM の DurationJavaType クラス内の非常に限定的なユースケースでも、 BigDecimal が先行して初期化されていました。これもすでに修正されています。

タイムゾーンの扱いが難しいことは誰もが知っています。しかし今、私たちはそのロードも遅いということを知りました。

タイムゾーンデータベースはかなり大きく、たとえば TimeZone.getDefault() を呼び出す際などにそれをロードすると、目に見えるほどの時間がかかることがあります。

サーバーアプリケーションでタイムゾーンを必要とする人なんているでしょうか？たとえば、ローカルのタイムゾーンでタイムスタンプを出力したいロギングレイヤーなどがそうです。

さらに興味深いのは、タイムゾーンを ZoneId に変換する際にも、ゾーンルールをロードする必要があるため、追加のコストがかかることです。

これら 2 つの問題は依然として存在しており、解決できるかどうかもわかりませんが、AOT 用に開発した特定のパッケージングを使用することで、Quarkus ではそのコストをある程度軽減することができました。