いつもはJEPで語れないだけですが、前回のエントリーで紹介したようにJava 24のAPIの変更はとても少なく、逆にJEPは24もあります。
そこで、今回はJava 24は24のJEPについて簡単に紹介していきます。
反応がよければ、シリーズ化するかも。
前回もリストアップしましたが、Java 24のJEPは以下の通り24になります。
- 404: Generational Shenandoah (Experimental)
- 450: Compact Object Headers (Experimental)
- 472: Prepare to Restrict the Use of JNI
- 475: Late Barrier Expansion for G1
- 478: Key Derivation Function API (Preview)
- 479: Remove the Windows 32-bit x86 Port
- 483: Ahead-of-Time Class Loading & Linking
- 484: Class-File API
- 485: Stream Gatherers
- 486: Permanently Disable the Security Manager
- 487: Scoped Values (Fourth Preview)
- 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)
- 489: Vector API (Ninth Incubator)
- 490: ZGC: Remove the Non-Generational Mode
- 491: Synchronize Virtual Threads without Pinning
- 492: Flexible Constructor Bodies (Third Preview)
- 493: Linking Run-Time Images without JMODs
- 494: Module Import Declarations (Second Preview)
- 495: Simple Source Files and Instance Main Methods (Fourth Preview)
- 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
- 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
- 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
- 499: Structured Concurrency (Fourth Preview)
- 501: Deprecate the 32-bit x86 Port for Removal
JEPで語れないシリーズでもそうですが、セキュリティ関連のJEP (JEP 478, JEP496, JEP 497)はさくらばがよく分かっていないので、省略します。
JEP 404 Generational Shenandoah (Experimental)
ShenandoahはRed Hatが中心となって作られているGCです。
Shenandoahはオブジェクトの世代を使用せずにGCを行うアルゴリズムでしたが、ZGCと同様に世代別GCを導入することになったようです。
Experimentalなのですぐに世代別GCを正式に導入するわけではないですが、次の次のLTSには世代別GCが正式になっていると思われます。
後ほど紹介しますが、ZGCは世代別GCだけを残すことになりました。今後、Shenandoahはどうするんでしょうね。
さて、世代別GCを使う方法です。
以下の実行時オプションを3つ指定します。
- -XX:+UnlockExperimentalVMOptions
- -XX:+UseShenandoahGC
- -XX:ShenandoahGCMode=generational
ただし、Oracle OpenJDKやOracle JDKはShenandoah GCを含まないので、Red Hat JDKやEclipse Temurinなどを使ってみてください。
JEP 450 Compact Object Headers (Experimental)
Javaのオブジェクトはヒープに配置されますが、オブジェクトにはヘッダーがつきます。
オブジェクトヘッダーはJVMの実装依存の部分なのでJVMSには定義されていないのですが、HotSpot VMの場合ヘッダーに128bit使用します。
しかし、小さいクラスだとヘッダーがバカになりません。
たとえば、record Point(int x, int y) {} なんていうクラスだと、データとしては8byte (64bit)しかありません。こうなると、ヘッダーの方が大きくなってしまうわけです。
そこで、現状128bitあるオブジェクトヘッダーを小さくするために立ち上がったのがProject Lilliputです。
Project LeadはAmazonのRoman Kennkeさん。数少ないOracleがリードではないプロジェクトです。
彼はJVMLSでProject Lilliputの講演をしているのですが、Lilliputの背景や概要についてはJVMLS 2023の講演が参考になると思います。
ちなみに、プロジェクト名のLilliputですが、ガリバー旅行記の出てくる小人の国のリリパット王国のことです。
なかなかいいプロジェクト名だと思いませんか？
Project Lilliputは、64bit VMと32bit VMの両方に対応していますが、ここでは64bit VMについて説明します。
オブジェクトヘッダーには以下のような情報が保持されます。
- GC Age
- 型(クラス)
- ロック
- ハッシュコード
GC Ageというのは、オブジェクトがGCから生き残ってきた回数を表します。世代別GCの場合、このAgeによってオブジェクトをYoung領域からOld領域に移動させます。
64bit VMではオブジェクトヘッダーが128bitで、上位64bitと下位64bitに分割されて使用されます。
上位64bitはマークワードと呼ばれ、ハッシュコード、GC Age、ロック情報が格納されます。ロック情報は下図のTagビットで表されます。
Mark Word (normal):
64 39 8 3 0
[.......................HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH.AAAA.TT]
(Unused) (Hash Code) (GC Age)(Tag)
下位64bitはクラスワードと呼ばれ、クラスポインターが格納されます。
Class Word (uncompressed):
64 0
[cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc]
(Class Pointer)
これに対し、Project Lilliputでは以下のようにヘッダーを64bitに抑えます。
Header (compact):
64 42 11 7 3 0
[CCCCCCCCCCCCCCCCCCCCCCHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHVVVVAAAASTT]
(Compressed Class Pointer) (Hash Code) /(GC Age)^(Tag)
(Valhalla-reserved bits) (Self Forwarded Tag)
これが実現されれば、多量のオブジェクトを使うシステムではかなりヒープ使用量が減るはずです。
ただし、ちょっと分からない部分もあります。上図のValhalla-reserved bitsです。
これはValue Class用のビットです。Value Objectはヒープの平坦化がされれば、オブジェクトヘッダーを使用しません。しかし、平坦化されない場合は通常のオブジェクトと同様にヘッダーを使用します。
この場合、通常のオブジェクトとValue Objectを区別するために上記のビットが使われることになると思われます。
Value Classが正式化されるまで、Previewのままなのか、それとも見切り発車で進んでしまうのか、どちらなんでしょうね。
Compact Object Headerを使用するには以下の2つの実行時オプションを使用します。
- -XX:+UnlockExperimentalVMOptions
- -XX:+UseCompactObjectHeaders
472: Prepare to Restrict the Use of JNI
498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
最近、OpenJDKではIntegrityがトピックになっています。
Integrityの意味は「誠実さ」とか「正直さ」などです。JavaでIntegrityってよく分からないですよね。
JavaのAPIや機能、ツールなどには黒魔術とも呼べるような安全ではない使い方ができるものがあります。
しかし、安全で堅牢なシステムを作成するにあたっては、このような機能は徐々に取り除いていかないとダメだよねというのが、JEP draft: Integrity by Defaultです。
また、このJEPの背景を語るドキュメントとしてPeaceful and Bright Future of Integrity by Default in Javaがあります。ありがたいことに、このドキュメントは西川さんが翻訳してくれています。
このJEPはまだdraftなので今後どうなるか分からないのですが、Java 24でもIntegrity by Defaultに関連したJEPがあります。それが、JEP 472とJEP 498です。
JEP 472がJNIの使用を制限するJEPで、JEP 498がsun.misc.Unsafeの使用を制限するというJEPです。
特にUnsafeはいろいろと危険なことができてしまっていたのですが、徐々に機能が減らされていって、最後に残っていたのがネイティブメモリへのアクセスだったのです。これに対し、安全にメモリにアクセス可能なFFMが提供されたので、ようやくUnsafeがお役御免となったわけです。まだ、Unsafeを使用すると警告が出るだけですが、だんだんと使えなくなっていくはずです。
475: Late Barrier Expansion for G1
G1GCの実装を改善しましょうというJEP。
バリアは何かしらを守るために使用される、同期方法の一種です。たとえば、CPUでメモリ操作の順序性を保証するために使われるメモリバリアなどがあります。
G1GCでもプリライトバリアやポストライトバリアなどのバリアが使われるのですが、そのバリアの処理が重いので、特にJITのC2コンパイラ使用時に改善していきましょうという提案です。
これはStandard JEPで、特に指定しなくてもG1GCを使用時には適用されます。
このJEPに関してThomas Schatzlが解説を書いてくれています。ありがたいことに、西川さんが翻訳してくれています。
479: Remove the Windows 32-bit x86 Port
486: Permanently Disable the Security Manager
501: Deprecate the 32-bit x86 Port for Removal
Integrity by Defaultとは関係ないのですが、機能を削除する関連のJEPがJEP 479、JEP 486、JEP 501です。
JEP 479とJEP 501は32bitのx86のポートを削除するJEPで、JEP 486が使わなくなったSecurity Managerを削除するJEPです。
483: Ahead-of-Time Class Loading & Linking
Javaは起動時間が遅いとよく言われますが、それを改善するためのプロジェクトがProject Leydenです。
Leydenとはライデン瓶のライデンですね。ライデン瓶は一種のコンデンサーで、導通した時に一気に電気を流せることからプロジェクト名になったんだと思います。あくまでも、櫻庭の予想ですが...
さて、Project LeydenではAOTコンパイラーが提供される予定ですが、その前にJEP 483で事前クラスローディングやリンクを可能とします。
Javaの起動時には様々な処理が行われます。その中でも、クラスロードし、クラスの解析、リンク、staticの初期化までの処理はシステムが大規模になればなるほど長い時間を必要とします。また、システムによっては、実行時アノテーションの解決も必要になります。
しかし、これらの処理は毎回同じことを繰り返すだけなので、その部分を事前にやってしまおうというのがJEP 483です。
実際には、トレーニング実行でこれらの処理をキャッシュとして保存しておき、本番時にはキャッシュを使用してシステムを起動します。
キャッシュファイルをapp.aotconfとした場合、以下のようにトレーニング実行、キャッシュファイルの保存という2段階でキャッシュファイルを作成します。
- トレーニング実行
$ java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar com.example.App ...
- キャッシュファイル作成
$ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
2番目のキャッシュファイル作成時にはアプリケーションは実行しません。
キャッシュファイルができたら、それを使用して実行します。
- 本番実行
$ java -XX:AOTCache=app.aot -cp app.jar com.example.App ...
484: Class-File API
Class-File APIはバイトコード操作のためのAPIです。
クラスファイルを解析したり、バイトコードで記述して直接クラスファイルを生成したりすることができます。
JDKの内部では動的にクラスを生成する場合などにバイトコード操作が行われてきました。この時に使用されていたのが、ASMです。
では、なぜ今になってASMではなくて、自前のバイトコード操作APIを作成することになったのでしょう。
クラスファイルにもバージョンがあり、バージョンが上がるごとに記述できる情報が増えていっています。しかし、サードパーティーのASMだと、最新のバージョンをサポートするまでに時間がかかってしまいまいます。
新しいクラスファイルをすぐにサポートするためには、やはり自前でバイトコード操作APIを作らないとダメということのようです。
Class-File APIでは、クラスファイルの読み、書き、改変をサポートしています。また、ストリーミング的な使い方と、イベント的な使い方の両方ができるようになっています。XMLでいうところのSAXとDOMのような使い分けができるはずです。
Class-File APIに関しては、今続けているバイトコード入門の続きとして紹介する予定です。
また、JJUGのナイトセミナーで少しだけ紹介したので、参考までに資料を張っておきます。
485: Stream Gatherers
Stream APIの中間操作をカスタマイズできるようにするのがStream Gathererです。
Stream Gathererに関しては、すでに解説エントリーを書いているので、そちらを参照してみてください。
487: Scoped Values (Fourth Preview)
Project Loomで策定されているAPIの1つであるScoped Valueはスレッド間でイミュータブルなデータを共有するための機能です。
今まで使用してきたThreadLocalはいろいろと問題があるので、それを全部ではないですけど、ある程度置き換えられる機能になっています。
4th PreviewでなかなかStandardにならないですが、次のJava 25でStandardになればいいかなという感じですね。
Java 24では1つだけメソッドが削除されて、一貫性のある使い方に整理されたようです。
488: Primitive Types in Patterns, instanceof, and switch (Second Preview)
パターンマッチングにプリミティブ型を使用できるようにしようというのがJEP 488です。
これのおもしろいのが、プリミティブ型の値とのマッチングと、型とのマッチングを同居させることができるところです。たとえば、こういう記述ができます。
switch(x) {
case 0 -> System.out.println("Zero");
case 1 -> System.out.println("One");
case int i when i > 100 -> System.out.println("Big int: " + i);
case int i -> System.out.println("Small int: " + i);
}
いろいろとルールはあるので、細かいところはJEP 488を読んでみてください。
489: Vector API (Ninth Incubator)
Javaでベクター処理を行うためのVector APIですが、Value Classが導入されるまではずっとインキュベータのままということになっています。
490: ZGC: Remove the Non-Generational Mode
ZGCはJava 23で世代別ZGCがデフォルトになりましたが、そうそうに元々の非世代別ZGCが削除されることになりました。
世代別と非世代別の両方をサポートするのは大変なのは分かりますが、そこまで急いで削除しなくてもいいのではと思ってしまいます。
491: Synchronize Virtual Threads without Pinning
Virtual Threadの使用時にsynchronizedを使うと、Virtual Threadを実行するキャリアスレッドをブロックしてしまうため性能が落ちるという問題がありました。
そのため、Virtual Threadを使う時にはsynchronizedではなく、ReentrantLockを使うようにしましょうというのが今までの解決法でした。
これに対し、synchronizedを使ってもキャリアスレッドをブロックしないようにするのがJEP 491です。
とはいえ、JEP 491が導入されれば、Virtual Threadでもsynchronizedを書き放題と思うのは早計です。
synchnronizedでもReentrantLockでも同期をするためにVirtual Threadをブロックします。キャリアスレッドのブロックよりはいいかもしれませんが、ブロックはブロックです。
Virtual Threadを使うようなスケールでは、些細なブロックでもできれば避けた方が賢明です。
ライブラリやフレームワークでsynchornizedを使用しているため、今までVirtual Threadを使っていても性能が出なかったという場合であればよいのですが、新たにVirtual Threadを使うコードを記述するのであれば、なるべくスレッドを独立にしてブロックしないような設計にするのがよいと思います。
492: Flexible Constructor Bodies (Third Preview)
コンストラクター内でスーパークラスや自分自身のコンストラクターをコールするのは、コンストラクターの先頭と決まっていました。
これに対し、フィールドの初期化の後にも書けるようにしたのがJEP 492です。
なぜこんなことが必要なのかというのと、Project Valhallaが関係しています。
Project ValhallaではValue Classの導入と、その効率化のためにNull非許容な型が導入されます。
しかし、コンストラクター内でスーパークラスのコンストラクターを先頭でコールしてしまうと、フィールドが初期化されていない状態でスーパークラスから参照できてしまいます。これはNull非許容の場合だと問題になります。
そのため、Value ClassやNull非許容型が導入される前に、JEP 492で問題となりそうな箇所をつぶしておこうというわけです。
Java 23の3rd Previewからの変更点はないので、Java 25ではStandardになるはずです。
493: Linking Run-Time Images without JMODs
JDKの標準ライブラリーはモジュール構成になっており、JARではなくJMODで提供されています。
当然、jlinkでランタイムを作成する場合もJMODがそのまま使われていました。これに対し、モジュールのJARでも可能にするようにしたのがJEP 493です。
494: Module Import Declarations (Second Preview)
import文にモジュール単位で記述できるようにするのがJEP 494です。
import module java.base;と書いておけば、java.langパッケージやjava.utilパッケージのクラスやインタフェースのimport文を書かずに済みます。
モジュール間で同じクラス名を使用している場合、明示的に優先的に使用するクラスのimport文を記述します。
たとえば、java.baseとjava.desktopをインポートしてしまうと、java.util.Listとjava.awt.Listなどの同じ名前のクラス/インタフェースをインポートしてしまいます。java.util.Listを優先的に使うのであれば、次のように記述します。
import module java.base; import module java.base; import java.util.List;
495: Simple Source Files and Instance Main Methods (Fourth Preview)
JEP 495は、mainメソッドの記述を簡素化するためのJEPです。
mainメソッドのためのクラスを書く必要がなくなり、void main() { ... }だけでOKになります。
また、標準出力への出力もSystem.out.println(...);ではなく、println(...);だけでよくなります。
このJEPもなかなかStandardになりませんが、Java 24での変更点はないので、このままJava 25でStandardになると予想されます。
499: Structured Concurrency (Fourth Preview)
JEP 499はProject Loomで策定されている仕様の1つです。
複数のスレッドの結果をまとめるためのAPIで、すべての処理結果を待つことや、失敗が1つでもあったら処理を失敗とするなどといったことが簡単に記述できます。
今までであれば、CompletableFutureを使えば同じようなことを記述できるのですが、Thread単体だとちょっと面倒でした。
そこで、Virtual Threadの導入とともにStructured Concurrencyが導入されるはずだったのですが、なかなかStandardにならないまま...
しかし、Java 24での変更はないので、Java 25でStandardになるのではないかと思うのですが、どうでしょう。
まとめ
というわけで、セキュリティ関連を除いてJava 24のJEPを簡単に紹介してきました。
最後の方はかなり簡単な紹介だけになってしまいましたが...
PreviewやIncubatorのJEPはStandardになった時に改めて紹介したいと思います。
