Java 28では、限定アリーナ(confined arena)に「プール」機能が入り、Windows、Mac、Linux上での処理について、小規模な割り当ての遅延が最大90%減る見込みです。対象はForeign Function & Memory APIを使い、Windows、Mac、Linuxでネイティブメモリを短命に確保する処理です。コード変更は不要で、安全性もそのまま維持されるのが特徴です。今日はこの最適化の仕組みと、実際にどんな場面で効いてくるのかを掘り下げます。

JDK 28、Confined Arenaの割り当てコストをプール化で圧縮

OracleのJavaチームメンバーによる情報発信であるInside.javaが2026年10月23日、JDK 28に搭載される最適化を伝えました。対象はForeign Function & Memory（FFM）API、Javaからネイティブコードを呼び出す際に使う仕組みです。かみ砕いて言えば、Javaのプログラムが外部の処理に「ちょっとこの値を渡したい」とメモリを一時的に借りるたびに、これまでは毎回きちんと手続きを踏んでいた、というイメージです。JDK 28からは、小さく短命な割り当てについてはこの手続きを簡略化し、割り当てにかかる遅延を最大90%減らせるとしています。Inside.java

Confined arenaは、ネイティブ呼び出しの前後だけ存在する「仮の置き場」として使われることが多い仕組みです。例えばシステムコールでエラー番号を受け取るときなど、使い終わればすぐに閉じて中身にアクセスできなくする、という使い方が典型的だといいます。問題は、たとえポインタ1つ、整数1つのような小さな値であっても、JDK 28より前は通常のネイティブアロケータを経由し、後片付け用の処理まで登録していた点です。出典記事は、この手続きのコストが実際にメモリへアクセスするコストを上回ることがあったと説明しています。

プルリクエスト提案者のMinborg氏、計測データでプール化の根拠を示す

この機能をプルリクエストとして提案したPer-Ake Minborg氏は、GitHub上でその開発の経緯を公開しているほか、dev.javaのニュース記事でもこのプール化による性能向上について執筆しています。JDKのソースコードとサードパーティライブラリを対象にした静的解析では、confined arenaはtry-with-resourcesブロック内でのみ使われており、構造化されていない使い方は見つからなかったといいます。そして割り当てられるメモリ量は「多くの場合32バイト未満、8バイト以下も少なくない」という結果でした。GitHub dev.java

実行時の計測でも傾向は一致しています。JDKのテストスイート(tier1)を1回フルで実行した際の記録では、confined arenaの半数近くが実際には何もメモリを割り当てておらず、非常に大きな割り当てを除き、割り当てたケースの99%以上は64バイト未満でした。Inside.javaの記事にある別の計測でも「割り当てを行ったconfined arenaのうち99.99%以上が64バイト未満」という近い数字が出ています。小さな値を頻繁にやり取りする使い方が大半を占めている、という点で両方のデータが合っています。この傾向を踏まえ、デフォルトでは64バイトのプールを4つ、スレッドごとに遅延生成する設計になりました。Minborg氏によるプルリクエストでは、5バイトの割り当てで「6倍から」という速度向上の数値が挙げられており、Inside.javaの原題では典型的な高速化を6〜18倍としている一方、提示された抜粋だけでは詳細な測定条件までは確認できませんでした。

プールの仕組みは次のようになっています。confined arenaが作られた時点ではプールを持たず、実際に割り当てが発生して初めてプールを確保します。プールは一度確保されると、そのarena専用になり、以降の割り当てはプールから順番に切り出されます。プールに収まらないサイズや、プールが保証できないアラインメント(メモリ配置の条件)を要求する割り当ては、従来通りの通常経路に回ります。arenaが閉じられると、使った分のプールはクリアされてスレッドのキャッシュに戻されます。出典記事はこの範囲までを説明しており、プールの配置戦略やキャッシュの内部実装の詳細には触れていません。この変更はOpenJDKの課題管理システムでJDK-8385697として追跡されています。bugs.openjdk.org

読者にとっての意味

出典記事が挙げる効果が及ぶ範囲は、confined arenaをネイティブ呼び出しのたびに作るFFMバインディング、jextractが生成するラッパー、ポインタの出力引数、短い文字列やバイト配列をネイティブコードへ渡す処理、頻繁に軽量なネイティブ呼び出しを行う処理などです。逆に、confined以外のarena種別にはこの最適化は適用されません。既存のコードはそのままで、割り当てが多い処理ほど恩恵を受けやすい、という理解でよさそうです。FFM APIを使ったコードを運用している、あるいはこれから採用を検討しているチームにとっては、JDK 28へのアップデート計画の中でこの変更点を確認しておく価値がありそうです。

用語補足：Confined Arena

Confined arenaは、JavaのFFM APIでネイティブメモリ(Javaのヒープ外にあるメモリ領域)を管理する仕組みの一種です。1つのスレッドに専有され、close()が呼ばれると確保していたメモリへのアクセスが即座にできなくなる、という厳格な寿命管理が特徴です。似た仕組みに他のarena種別もありますが、今回の最適化が適用されるのはconfined arenaに限られます。本記事で紹介した「割り当て遅延を最大90%削減」「6倍からの速度向上」といった数値も、あくまでconfined arenaを使い、かつ小さく短命な割り当てを行うケースに限った話です。すべてのネイティブメモリ処理が同程度に速くなるわけではない、という点は押さえておく必要があります。

注目ニュース

ペンシルベニア州、AI生成広告へのラベル表示を義務化

ペンシルベニア州のジョシュ・シャピロ知事は木曜日、AI生成広告に開示表示を義務づける「Artificial Intelligence Deceptive Advertising Act」に署名しました。静止画、動画、音声、テキストを問わず「AIによって大幅に改変または生成された」広告には、その広告自体と同じ形式でラベルを付ける必要があります。対象は大企業のテレビCMから、飲食店のチラシまで幅広く及びます。ただし何をもって「大幅に改変された」とするかは主観的な判断に委ねられており、パロディや風刺、「明らかにフィクションと分かる」内容には適用除外が設けられています。また文言上は、商品やサービスについて誤った消費者認識を生じさせるような合成コンテンツの利用に限って開示を求めているとも読め、どこまでが対象になるかは曖昧さが残ります。この法律の対象は同州外で制作された広告にも及ぶため、他州のテレビCMでもラベル表示が見られるようになる可能性があります。この法案を提出したニック・ピショッターノ州上院議員の事務所は、The Vergeの取材依頼にすぐには応じなかったとのことです。The Verge

編集後記：64バイトという境界線

今回の最適化で印象に残るのは、デフォルトのプールサイズが64バイトに設定された経緯です。Inside.javaが示した計測で「割り当てを行ったconfined arenaの99.99%以上が64バイト未満」だったという数字が、そのまま設計の根拠になっています。出典記事自身が「テストスイートのワークロードはすべてのアプリケーションを代表するものではない」と断っている点も見逃せません。自分たちのアプリケーションがこの傾向に当てはまるかどうかは、結局のところ実際に動かして確かめるしかなさそうです。JDK 28がリリースされたら、FFM APIを使う処理のプロファイルを取り直してみる価値はありそうです。