原文はこちら。
The original article was written by David Delabassee (Director, Java Developer Relations, Oracle).
https://inside.java/2024/02/21/quality-heads-up/
OpenJDK Quality Groupは、リリースの全体的な品質向上の手段としてOpenJDK Early Accessビルドを使ってのFOSSプロジェクトのテストを推進しています。
Quality Outreach
https://wiki.openjdk.java.net/display/quality/Quality+Outreach
このHeads upは、関係するプロジェクトに送られる定期的なコミュニケーションの一部です。
JDK 22 Release Candidates & Virtual Threads pinning heads-up
https://mail.openjdk.org/pipermail/quality-discuss/2024-February/001133.html
このプログラムの詳細と参加方法については、上記wikiをご覧ください。
Heads-up: Virtual Threads “Pinning” Issue
Virtual threadsはJDK 21で恒久的な機能になりました。この機能はJavaエコシステムから非常に高い評価を得ていますが、まだいくつかの問題が残っています。synchronizedメソッドやsynchronizedステートメントで発生する、いわゆるpinning問題について多く取り上げられています。最も一般的な2つのケースは以下の2件です。
- synchronizedメソッド中にvirtual threadがとまる(socket I/Oを行うなど)
- オブジェクトの関連するモニタを別のスレッドが保持しているため、virtual threadがsynchronizedメソッドに入るのをブロックする
どちらの場合も、基盤となるキャリア/ネイティブスレッドは他の作業を行うために解放されません。パフォーマンスとスケーラビリティが低下し、場合によってはstarvationやデッドロックが発生する可能性があります。この最近リリースされたVirtual Threads Next Stepsの動画では、その理由を詳しく説明し、いくつかの潜在的な解決策について論じています。
Call-to-Action
最近、新しいLoom早期アクセスビルドが公開されました。これらのLoom EAビルドでは、オブジェクトモニタの実装が変更されており、これら2つの一般的なケースのためにpinningしていません。
Loomチームは、virtual threadsを使用していることが分かっているコードや、同期を多用しているライブラリで、このアップデートされたオブジェクトモニターのテストのために、みなさまの助けを必要としています。目的は、信頼性とパフォーマンスの両方を測定することです。
問題やフィードバックを報告するには、Loomメーリングリストを利用するのが最も簡単です。VMに詳しい方は、-XX:LockingMode=1(現在のデフォルト)と-XX:LockingMode=2の両方でテストしてくださると、現在HotSpot VMで実装されている2つのロックモードを使うため、非常に助かります。