Foreign Function & Memory (FFM) API は、オフヒープメモリに安全にアクセスするために MemorySegment を導入します。各セグメントは、そのライフサイクルを定義する MemorySession（または新しいバージョンでは Arena）に関連付けられています。アリーナが閉じられると、ScopedMemoryAccess レイヤーはすべての関連セグメントを「生きていない」とマークします。
その後のアクセス試行は、すぐに IllegalStateException をスローする ScopedMemoryAccess.Scope チェックをトリガーします。ネイティブ操作が進行中の間にガーベジコレクタがセグメントを回収するのを防ぐために、JVM は暗黙的に reachabilityFence セマンティクスを使用します。コンパイラは重要な境界に保存バリアを挿入し、ネイティブ呼び出しが完了するまでセグメントオブジェクトが強く到達可能であることを保証します。
この調整により、close() での明示的な決定的クリーンアップが可能になり、GC がセグメントを早く終了させると発生する use-after-free エラーを防ぎます。この設計により、すべてのアクセスのために手動同期を必要とせずにメモリ安全性が維持されます。このアーキテクチャの選択は、手動メモリ管理とJavaの自動ガーベジコレクションパラダイムの間のギャップを埋めます。
C++ の取引所ゲートウェイと共有されるオフヒープバッファにマッピングされた MemorySegment を介して市場データを処理する高頻度取引アプリケーションを考えます。問題は、複数のスレッドがプライシングの更新を読み取ろうとするときに発生します。バックグラウンドのメンテナンススレッドが定期的に古い Arena を閉じて新しいものを割り当てるときに発生します。適切な時間的安全性がない場合、リーダースレッドが、基礎となるメモリがオペレーティングシステムに返却されたセグメントにアクセスしようとすることがあり、JVMのクラッシュやサイレントデータ腐敗を引き起こす可能性があります。
検討された解決策の1つは、AtomicInteger を使用した明示的な参照カウントです。各読み取り操作はカウンタをインクリメントし、完了後にデクリメントします。利点は、簡単な論理とリークの即時検出です。ただし、欠点は高負荷時に原子変数上の競合が大きく、ガーベジコレクタとの統合に失敗することです。デクリメントを忘れると依然としてメモリがリークし、ネイティブコードが生ポインタを保持している間にアリーナが閉じるのを防げません。
別のアプローチは、すべてのアクセスをラップする try-with-resources ブロックを使用して、操作中にアリーナが開いたままになるようにすることでした。利点は決定論的なスコーピングとクリーンな構文です。欠点は、短命の操作に対してアリーナの過剰な閉鎖と再オープンが発生し、1秒あたり数千のセグメントを割り当てる際には非常に高コストとなります。さらに、このパターンは、Java スコープを超えて生きる可能性のあるネイティブコードからの非同期コールバックを保護できません。
選択された解決策は、適切な reachabilityFence 配置とスコープアクセスチェックを持つ Arena.ofShared() を利用しました。アリーナの閉鎖を専用のメンテナンススレッドに制限し、すべての読み取り操作がデリファレンスする前にセグメントの生存性を検証することで、システムは競合状態を排除しました。ScopedMemoryAccess メカニズムは、速いパスでのコストゼロのチェックを提供、一方で JVM の到達可能性保証が GC の干渉を防ぎました。その結果、ネイティブのクラッシュやメモリリークなしで、毎秒何百万ものメッセージを処理できる安定したシステムが実現しました。
なぜ MemorySegment は、セグメントが明示的に制限されていない場合でも WrongThreadException をスローするのか、また Arena タイプがスレッドの制約セマンティクスをどのように決定するのか？
多くの候補者は、すべてのセグメントがデフォルトでスレッドセーフであると仮定します。実際には、Arena.ofConfined() は、オリジナルスレッドだけがアクセスできるセグメントを作成し、ScopedMemoryAccess におけるスレッドIDチェックによって強制されます。Arena.ofShared() はスレッド間のアクセスを許可しますが、外部の同期が必要です。この例外は、制限されたセグメントのアドレスがラムダやコールバックを介して別のスレッドに渡されたときに発生します。
オフヒープリソースがネイティブ呼び出し中に有効であることを保証する際、reachabilityFence メカニズムは PhantomReference とはどのように異なるのか？
候補者はしばしばこれら二つのメカニズムを混同します。PhantomReference は、オブジェクトが到達不可能になった後の後処理クリーンアップを許可しますが、これはアクティブな操作中の use-after-free を防ぐには遅すぎます。reachabilityFence は、フェンスが実行されるまでオブジェクトを強く到達可能に保つコンパイラ挿入バリアとして機能します。FFMでは、JVM はこれらのフェンスを自動的に MemorySegment アクセサーの周りに挿入し、ユーザーコード内での手動配置を必要とせず、ネイティブメモリアクセス全体でセグメントが生き続けることを保証します。
直接 MemorySegment を閉じる場合とその親 Arena を閉じる場合の違いは何であり、なぜアリーナを閉じるとすべての派生セグメントが同時に無効化されるのか？
一般的な誤解は、セグメントが独立したリソースであるということです。実際には、slice() または reinterpret() を介して生成されたセグメントは、その親アリーナと同じ ScopedMemoryAccess.Scope を共有します。Arena.close() が呼び出されると、全体のスコープが無効化され、すべての派生セグメントに cascades します。個々のセグメントを閉じることは、その特定のビューを無効とマークするだけですが、基礎となるメモリはアリーナが閉じるまで割り当てられたまま残ります。