2017年第２四半期に予定されるJava 9一般公開が近づき，多くのJEP提案も最終段階に入り始めている。中心的な存在となることが確実視されるJEP 261(モジュールシステム)は，JSR 376で定義されたJava Platform Module Systemの導入に関する提案である。このモジュールシステムJEPはJEP 260(内部APIの大半をカプセル化する)に依存しており，結果的にこれまで議論の的であったsun.misc.Unsafeクラスの機能を，JEP 193の定義する変数ハンドルを通じて外部に公開することになる。InfoQでは以前にも，sun.misc.Unsafeの取り扱いに対する(JEP 260提案以前の)コミュニティの懸念と，想定される(JEP 260実装後の)移行計画を詳細にお伝えしている。
JDK Bug Systemに先日ポストされたBug 8149159では，パラメータチェックのネイティブ層からJavaへの移行(JITの簡略化が可能になる)，sun.misc.Unsafeとjdk.internal.misc.Unsafeの統合，ネイティブコード全般のクリーンアップなど，最適化とクリーンアップが提案されている。
2月18日，OracleのエンジニアであるMikael Vidstedt氏が，OpenJDK開発者コミュニティのレビューを受けるべく，２つのパッチ(OpenJDK用とOpenJDK HotSpot VM用)を提出した。
氏はパッチの内容を次のようにまとめている。
- jdk.internal.misc.Unsafeへの移行が完了した，sun.misc.Unsafeのコードの重複回避。これにはVM - 特にunsafe.cpp - で，s.m.Unsafeに注意を払う必要がなくなるという意味もある。
- s.m.Unsafeデレゲーションメソッドはアノテーションなしでもインライン化される可能性が高いが，パフォーマンス低下のリスクを最小限にする目的で，すべて@ForceInlineを指定した。
- ドキュメントを更新して，変数の有効性保証がUnsafe使用者の責任であることを明記した。
- パラメータチェック処理を可能な限りunsafe.cppに移動して，ネイティブコードの簡素化とJITによる最適化を可能にした。
- 一部のパラメータチェックの緩和。例えば，最近導入されたU.copySwapMemoryでは，nullポインタチェックは行なわない。この対応の根拠については，j.i.m.U.checkPointerのドキュメントを参照のこと。U.copySwapMemoryを除く現在のUnsafeメソッドでは，NULL関連のチェックを行っていないことも注意が必要である。
- U.copySwapMemoryをベースとしたテストをj.i.m.U.copyMemoryにも追加した。統一すべきであれば，その旨指摘してほしい(本来ならばそうすべき)。
Vidstedt氏は，Unsafeのクリーンアップは“かなり過激”な変更であるとして，次のような点を指摘する。
- unsafe.cppの他のローカル関数と同じように，Unsafe_関数もstaticとして宣言されるようになった。
- unsafe.hppが追加されて，VMの他の部分で使用されている関数のいくつかが移動された。また，いくつかの“extern”関数宣言が削除された(externの(過)使用は可読性を損なう)。
- UNSAFE_LEAFが使用不可であるという的外れなコメントが削除された – 何ということはなく，単にJVM_LEAFを使用すればよい。
- 簡単なリーフメソッドのいくつかで，UNSAFE_LEAFが使用されている。
- 自動インデント処理を考慮して，UNSAFE_ENTRY/UNSAFE_ENDを分かりやすくする括弧が追加された。
- 使用されていなかったUnsafe_<...>##140関数とマクロが削除された。
- unsafe.cppのマクロ定義全体が一貫性を持つように，マクロ引数の名称が変更された。
- いくつかのチェックをアサートにした – 前述のように，j.i.m.Unsafeでチェックが行なわれるようになったため。
- s.m.Unsafe関連のコードがすべて削除された。
この記事を評価
- 編集者評
- 編集長対応
提出
提出