特に気になった点だけ調べてみた。
ウォームアップ短縮（JEP 515）
Java アプリケーションは JIT コンパイルによって実行速度を最適化するが、その「最適化」に到達するまでのウォームアップ時間は長年の課題だった。特に短命なサービスやバースト型のワークロードでは、起動直後のレスポンス低下が無視出来ない。
JEP 515 では、過去の実行から収集したプロファイル情報を AOT キャッシュとして保存し、次回の起動時に利用できる仕組みが導入された。これにより、
- 初期起動から JIT 最適化が効いた状態に近いパフォーマンスを発揮
- マイクロサービスやサーバレス環境の「コールドスタート問題」を緩和
- ウォームアップを待たずにスループットやレイテンシが安定
といったメリットがある。
トレーニング実行（プロファイル収集）
まずはアプリを「本番に近い負荷テスト」、「代表的な入力データ」等で実行し、JIT がどのメソッドをよく使うかを記録する。
java -XX:AOTCacheOutput=app-prof.aot -jar myapp.jar本番実行（プロファイル利用）
保存したプロファイルを読み込み、本番環境で起動する。
java -XX:AOTCache=app-prof.aot -jar myapp.jarCompact Object Headers（JEP 519）
Java のオブジェクトはヒープ上で管理され、各オブジェクトには「ヘッダ情報」が付与されている。従来は 12 バイトが標準だったが、JEP 519 では ヘッダを 8 バイトに圧縮するオプションが提供された。
これにより、
- メモリ削減：多数の小さなオブジェクトを扱うアプリで特に有効。ヒープ効率が上がるため GC 回数も減少する。
- キャッシュ効率の改善：メモリ占有が減ることで CPU キャッシュに収まるデータ量が増え、アクセスレイテンシが低下する。
- スループット向上
利用方法は、JVM 起動時に以下を指定する。
java -XX:+UseCompactObjectHeaders -jar myapp.jarデフォルトでONになっていないということは、全ての環境で改善するわけではないことを表している。
- COH ではオブジェクトヘッダに格納されていた情報を圧縮／再配置するため、hashCode／同期多用のアプリでは遅くなる可能性
- ヒープダンプ解析ツールや JVMTI を使った低レベルの計測では、
オブジェクトレイアウトが従来と変わるため、互換性のリスクあり - メモリ帯域が十分に広いサーバー、CPU キャッシュが大きい最新世代のCPUでは効果が限定的になる場合がある（逆に、組込み系やクラウドVMのようにメモリ制約がある環境で効果大）
適用シナリオ
これらの最適化はすべてのアプリケーションで均等に効くわけではない。効果が大きいシナリオは以下の通りとなる。
ウォームアップ短縮（JEP 515）
- サーバレス、マイクロサービス
- 短命な CLI ツールやバッチ処理
Compact Object Headers（JEP 519）
- ヒープ上に数百万単位のオブジェクトを保持するシステム
- 高トラフィックの Web サービス
- データ処理や分析基盤
まとめ
Java 25 の JEP 515 と JEP 519 は、単なる言語仕様の追加ではなく、実行基盤のボトルネックを狙い撃ちした改善となっている。
起動直後のパフォーマンスが課題であればウォームアップ短縮を、ヒープ使用量やGCコストに悩んでいるなら Compact Object Headers を試す価値がある。