JVMCI（JVM Compiler Interface）は、JVMのクラス・メソッドなどのメタデータへアクセスし、生成したマシンコードをJVMに組み込むインターフェースを提供します。極めて端的に言ってしまえば、Javaでコンパイラを作るための機能です。
Javaに関連するコンパイラというと、javacやJITコンパイラ、AOTコンパイラなどが思いつきますが、これらを使うことはあっても、作ることなんてないですよね。
JVMCIはコンパイラを作るマニアックな上級者向けの機能と言えるでしょう。
そんなJVMCIは、2026年9月15日にリリースされるJDK 27で完全に削除されます。
本稿では、JVMCIの削除が提案された背景から、削除が提案されてからのOpenJDKコミュニティでの議論を説明します。
そして、JVMCIに強く依存してきたプロジェクトの中から比較的知名度の高いGraalVMとTornadoVMを例に、それらがこれからどうなるのかを見ていきます。
JVMCI削除の背景
事の発端は、2025年9月にリリースされたJDK 25以降、OracleがOracle Java SEの製品ラインナップからGraalVMを外したことだと私は考えています。
原文記事
Detaching GraalVM from the Java Ecosystem Train
OracleがGraalVMの開発をやめたわけではありません。Oracle GraalVM - Release Calendarでリリース計画が公開されています。
GraalVMの魅力は、Graal JITやNative Imageといった機能によってJavaアプリの起動時間や暖気時間を短縮できる点にあります。しかし、同じ目的を実現しようとするOpenJDKのProject Leydenも、これとは異なるアプローチで並行して開発が進められていました。
数年にわたって2つのアプローチを並行して進めた末、Oracleは成果やフィードバック、将来性を総合的に評価し、今後はProject Leydenの開発に注力するという結論に至りました。
その結果、Oracle JDK 24までは実験的オプションとして提供されていたGraal JITは、Oracle JDK 25以降は提供されないことになりました。
Graal JITは内部でJVMCIを利用しています。Graal JITの導入を提案したJEP 317: Experimental Java-Based JIT Compilerを読むと強い関係性があるとわかります。
さらに立ち戻って、JVMCIの導入を提案したJEP 243: Java-Level JVM Compiler Interfaceを見ると、Descriptionの中で以下のように書かれています。
An excellent demonstration of using JVMCI to write and deploy a high performance compiler in the JVM is provided by Graal which has demonstrated peak performance on par with C2 across a wide range of benchmarks.
（JVMCIを使って高性能なコンパイラをJVM上に実装・展開した優れた実例としてGraalが挙げられ、C2に匹敵するピーク性能を達成している）
つまり、JVMCIが提案された当初からその実証例として名指しされているコンパイラはGraalであり、JVMCIはGraalのために作られた機能という側面があると言えるでしょう。
もっとも、同じJEP 243のNon-Goalsセクションには次のようにも書かれており、
Integration of a dynamic compiler (such as Graal) based on JVMCI.
（Graalのような動的コンパイラをJVMCIに基づいて統合すること）
JEP 243は「JVMCIの提供」と「Graalの提供」を明確に分け、JVMCIがGraal専用の機能ではないとしています。とはいえ、提案当初から実証例として名指しされるコンパイラがGraal以外に存在しない以上、実質的にJVMCIの必要性はGraalの存在に強く依存してきたと言えるでしょう。
ここで、Graal JITを無くすのであればJVMCIをJDKでサポートし続ける必要はあるのか？という話が出てくるのです。
JVMCI削除を巡る議論と決着
2026年4月20日、JVMCIの削除はBugID JDK-8382582として提案されました。
提案された当初、BugIDに記載されていた説明は非常に簡素で、『JVMCIはGraal以外で実質的に使われていないにもかかわらず、JVMCI特有の処理がJVM中に散見され、保守のオーバーヘッドになっている』との内容が記載されているだけでした。
ここでの「Graal」は、OpenJDKで提供されていたGraal JITではなく、GraalVMで提供される機能のことを指します。
削除を提案するBugIDが起票されたことを受けて、OpenJDKのメーリングリストで反対意見が寄せられました。
反対意見の主張は以下です。
-
Graalの起動速度や暖気速度の短縮はProject Leydenでカバーされるかもしれないが、Polyglot機能はどうなのか。Project Detroitで代替機能が提案されているものの、成果物がまだ出てきていない。
-
Graal以外にも、TornadoVMなど現実世界で使われているプロジェクトはJVMCIに依存している。
このとき、単に反対意見を言うだけでなく、『我々がJVMCIを維持する役割を担うので、Project Detroitの先行きが見えるまで削除は待ってくれないか。』という主張がされました。
もちろん、反対意見を主張したJDKベンダの組織的な意図があってのことだと想像しますが、かなりのコストがかかることは目に見えているので、そこまで言ってのけるのは凄いなと私は感心していました。
上記の主張を受け、削除を提案した方はJDK-8382582のDescriptionにJVMCIを削除するモチベーションをより詳しく述べました。以下に一部を抽出します。
-
JVMCI関連コードはコンパイラ、ランタイム、GC、サービサビリティ、テスト、ビルドなどJDK全体に散見され、252個の
#if INCLUDE_JVMCIブロックが存在する。また、直近1年でJVMCIの修正を主目的としないコミットのうち約1.5%（75件）がJVMCI関連コードに影響を与えていた。 -
HotSpotの通常の開発で意図せずJVMCIの機能を壊すことがあり、その対応で開発の遅延が複数回発生してきた。Project Valhallaもこの影響を受けており、JVMCIのためのフォールバック実装を強いられている。
-
もともとJVMCIはJavaベースコンパイラの実験を促進するためにJDKへ導入され、実験がうまくいけば大規模な改修が行われる前提であった。しかし、Project GalahadやProject Metropolisも撤退された今、JVMCIが将来的にもたらしうるメリットは大幅に縮小した。
削除するモチベーションの3つ目より、
『JDKのJITコンパイラを、C/C++で書かれたHotSpotのものから、Javaで書かれたGraalのものに移行するという10年来の大規模な実験が失敗に終わった』と言えるでしょう。
この詳細な説明を受け、削除に反対意見を表明した方からも納得したとの旨が投稿されました。
その後もJVMCIの削除を惜しむ声は各所で上がったものの、JVMCIを維持するメリットは提示されず、削除されることが決定しました。
JVMCIを削除するプルリクエストは約1か月のレビュー期間を経て承認されました。
19名からのコメント、873行の追加、82,292行の削除と非常に大規模な変更でした。
JVMCIに依存していたプロジェクトのこれから
JVMCIに依存していたプロジェクトには3つの選択肢が与えられます。
-
JDK 27以降のサポートをあきらめる
-
独自でJVMCIをサポートし続ける
-
JVMCIに依存しないコードへ刷新する（脱JVMCI）
メーリングリストの議論にも出てきた2つのプロジェクトを例に見てみましょう。
GraalVM
※2026年9月15日19時、更新。
本稿の投稿後、GraalVM ProjectのLeadであるThomas WuerthingerさんからXでリプライが届き、GraalVMの開発方針を補足いただきました。
The @GraalVM team at Oracle continues to develop the Java JIT compiler in Java based on JVMCI as part of the GraalVM open source project. In the future, it will just not be supported in HotSpot, but will continue to have support in SubstrateVM. The removal of JVMCI is specific to OpenJDK.
（Oracleの@GraalVMチームは、GraalVMオープンソースプロジェクトの一環として、JVMCIをベースにしたJavaベースのJava JITコンパイラの開発を今後も続けます。将来的には、HotSpotではサポートされなくなり、SubstrateVMでのサポートが継続されます。JVMCIの削除はOpenJDK固有の話です。）
OpenJDKではJVMCIが削除されたため、HotSpotでJVMCIに基づくJava JITコンパイラ（Graal JIT）を利用することは今後サポートされません。
一方、JavaアプリケーションをAOTコンパイルしてNative Imageを作成するSubstrateVM（GraalVMの内部プロジェクトの一つ）では、JVMCIをベースにしたGraal JITの開発は継続されるようです。
ところで、Graal JITはHotSpotのC2コンパイラを置き換える形で使われてきました。OpenJDKでJVMCIがサポートされなくなった今、HotSpotはGraal JITをロードできませんが、これからGraal JITはどこで使われるのでしょうか。
この疑問についてThomasさんに質問したところ、以下の回答をいただきました。
With Crema, arbitrary dynamically loaded and JIT compiled Java workloads can be executed on SubstrateVM and HotSpot is no longer required for this mode.
（Cremaにより、任意の動的ロードやJITコンパイルされたJavaワークロードをSubstrateVM上で実行できるようになります。このモードでは、HotSpotはもはや不要になります。）
ここで登場したのがProject Cremaです。
Project CremaはGraalVMのプロジェクトの一つで、SubstrateVM上で任意の動的ロード、およびJITコンパイルされたJavaワークロードを実行できるようにします。
つまり、SubstrateVM上でGraal JITを利用可能とするのです。
Project CremaのGitHub Issueを見る限り正式なリリースはされていないものの、Thomasさんの発言からは実際に動くところまで来ていることが伺えます。
JDK 27 takes shape, while GraalVM changes the release cadence - JVM Weekly vol. 176によると、GraalVMはJava 26、27、28の非LTSバージョンのリリースをスキップし、直接Java 29をターゲットにする計画です。
Java 29に対応したGraalVM 29のリリースに向けて、Project Cremaがどのように進化を遂げていくのか注目です。
TornadoVM
TornadoVMはマンチェスター大学の研究から生まれたフレームワークで、JVMのバイトコードをCUDAやOpenCLなどに対応したGPU向けコードにJITコンパイルすることを可能とします。このJITコンパイルの部分にJVMCIを活用していました。
JVMCI削除の直接的な影響を受けることから動向が注目されていましたが、Java 27がリリースされるより約2週間前にTornadoVM 6.0.0をリリースし、その中で脱JVMCIに成功しました。
原文記事
TornadoVM 6.0.0: JVMCI-Free, JDK 21–27 Compatible, Zero JNI, and a Leaner Core
TornadoVMをJDK 27で使うとしてもJVMCI削除について気にすることは何もありません。
プルリクエストを見ると差分の規模も大きく、簡単な修正ではなかったと思われます。関係者らによって迅速に対応された素晴らしい結果です。
さいごに
JVMCIの削除はJDK開発者らが10年以上かけて行ってきた「JDKのJITコンパイラをJavaで開発する実験」の後片付けと言えるでしょう。失敗で終わってしまったのは残念ですが、挑戦無しにはイノベーションは生まれません。
前向きな側面として、JVMCIのしがらみを気にしなくてよくなることで、JVM開発のスピードアップが期待されます。
同じく10年以上開発が続けられてきたJEP 401: Value Objects (Preview)がJDK 28をターゲットとすることが最近知らされたのも偶然だけではないのかもしれません。
役目を終えたオブジェクトが回収されて初めて、次の世代のために新しいヒープ領域が生まれる。JVMCIの削除もまた、JDKにとってのそうした世代交代のひとつなのかもしれません。