Oracle GraalVM for JDK 24

(2025-03-18)

プラットフォームとディストリビューション
JDK 24の機能の利用可能性
Graalコンパイラ
ネイティブ・イメージ
ポリグロット・ランタイム
GraalJS
GraalPy
GraalWasm
Espresso
Truffle言語実装フレームワーク

プラットフォームとディストリビューション

Oracle JDK 24に基づいたOracle GraalVM for JDK 24がリリースされました。「Java SE 24リリース・ノート」を参照してください
バージョン互換性:
- GraalVM for JDK 24は、Graal言語およびその他のコンポーネントのバージョン24.2.0と互換性があります。

機能

Graalコンパイラ

JVMCIスレッドのデフォルト数は、C2スレッド(-XX:JVMCINativeLibraryThreadFraction=0.66)と同じになりました。これによりプログラムのウォームアップは改善されますが、最大RSSが増加する可能性があります。-XX:JVMCINativeLibraryThreadFractionを小さい値に設定すると、最大RSSは小さくなりますが、ウォームアップは長くなる可能性があります。(JDK-8337493を参照してください。)
レガシーのgraal.接頭辞を最初に使用したときに非推奨の警告を表示します。この警告は、JDK 26以降のGraalVMでエラーにアップグレードされます。

ネイティブ・イメージ

改善および新機能

このリリースでは、機械学習を利用した新しい世代のプロファイル推論(Graal Neural Network (GNN)静的プロファイラ)が導入され、幅広いマイクロサービス・ベンチマークでピーク・パフォーマンスが7.9%向上しました。この最適化を有効にするには、-O3オプションをネイティブ・イメージに渡します。この機能は、Oracle GraalVMでのみ使用できます。詳細は、ドキュメントを参照してください。
SkipFlowの導入: 分析プロセス中にプリミティブ値を追跡し、分岐条件を動的に評価するネイティブ・イメージ静的分析に対する新しい実験的な拡張。SkipFlowは、ビルド時間に追加の影響を与えることなく、バイナリ・サイズを最大4%削減できます。この機能は、GraalVM for JDK 24で使用できますが、デフォルトでは有効になっていません。次のオプションを使用して有効化およびテストします: -H:+TrackPrimitiveValuesおよび-H:+UsePredicates。この機能強化は共同研究の成果です。詳細は、こちらの論文を参照してください。
実行時にJavaエージェントのpremainメソッドを実行するための実験的なサポートが追加されました。ビルド時に、-H:PremainClassesオプションを使用してpremainクラスを指定します。実行時に、メイン・クラスの引数とともに、-XXpremain:<class>:<options>という書式でpremain実行時オプションを指定します。(#8988を参照してください。)
ネイティブ・イメージAOTコンパイルにおける実験的なベクターAPIサポートが強化され、Graal JITと同等になりました。ネイティブ・イメージのビルド時にベクターAPIの最適化を有効にするには、--add-modules jdk.incubator.vectorおよび-H:+VectorAPISupportオプションを使用します。(#10285を参照してください。)改善点としては、最適化されたベクターAPI操作の数の増加などがあります。次の操作は、ターゲット・ハードウェアでサポートされているSIMDコードに効率的にコンパイルされるようになりました:
- ベクターAPIマスクの操作
- マスクされたベクターAPIのロードとストア
- 一般的なベクターAPIの再配置操作
- メモリー・セグメントとの間でのベクターAPIのロード/ストア
直接メソッド・ハンドルの特殊なアップコールを導入することで、ネイティブ・イメージの外部関数およびメモリーAPI (FFM)を最適化しました。
GraalVMネイティブ・イメージのソフトウェア部品表(SBOM)のサポートが強化され、セキュリティが向上し、アプリケーションの依存関係に関するより深いインサイトが提供されます:
- クラス・レベルのメタデータの包含: --enable-sbom=class-level,exportオプションを使用して、ネイティブ・イメージのSBOMコンポーネントにクラス・レベルのメタデータを含めることができるようになりました。この情報は、高度な脆弱性スキャンおよびイメージの内容の理解を深めるために役立ちます。
- 依存関係ツリーの生成: SBOMには、静的分析から導出された詳細な依存関係ツリーが含まれるようになりました。この機能により、ネイティブ実行可能ファイル内のコンポーネントの依存関係が階層的に表示されます。
- 脆弱性スキャンに不可欠なSBOMの精度の向上: GAV座標は、マニフェスト・ファイルの解析と処理を拡張し、ネイティブ・イメージMavenプラグインと統合することで、より正確になりました。これにより、偽陰性が減少します。シェーディングJARおよびファットJARは、冗長コンポーネントを削除し、脆弱性スキャンの誤検出を減らすために、より適切に処理されるようになりました。
詳細は、ドキュメントを参照してください。
リフレクション・エントリにserializableフラグを導入することで、シリアライズJSON到達可能性メタデータをリフレクション・メタデータの一部として含めます。
ネイティブ・イメージに含まれるリソースのオリジンを保持します。この情報は、デフォルトでビルド・レポートに含まれています。または、-H:+GenerateEmbeddedResourcesFileオプションを渡して生成できます。
JNIでGetStringUTFLengthAsLongのサポートが追加されました。(JDK-8328877を参照してください。)
-XX:MissingRegistrationReportingMode=Warnの使用時に出力されるスタック・トレースの長さを-XX:MissingRegistrationWarnContextLines=で設定できるようになりました。デフォルトの長さは8です。
分離またはVMの作成中にActiveProcessorCountを設定する必要があります。
NativeImageOptions.NumberOfThreadsで設定された値を一貫して尊重するようにForkJoinPool.commonPool()ビルダー・メソッドを最適化しました。
指定したタイプのオブジェクトがヒープ・スキャン中に到達可能としてマークされたときに実行されるコールバックを登録できるように、DuringSetupAccess.registerObjectReachabilityHandlerが追加されました。

プラットフォーム互換性

ネイティブ・イメージは、AArch64でデフォルトでarmv8.1-aをターゲットにするようになりました。ネイティブ実行可能ファイルが同じマシンまたは同じCPU機能を持つマシンにデプロイされる場合、最高の互換性のためにビルド時に-march=compatibilityを渡すか、最高のパフォーマンスを得るために-march=nativeを渡します。使用可能なすべてのマシン・タイプをリストするには、-march=listを使用します。
Javaモジュール・システムベースのサービス・ロードのサポートが追加されました。たとえば、module-info.javaファイルで次を定義します:
```
module Foo {
    provides MyService with org.example.MyServiceImpl;  
}  
```

デバッグおよびモニタリングの改善

LinuxおよびmacOSでのjcmdの実験的なサポートが追加されました。--enable-monitoring=jcmdオプションを使用して、jcmdを有効にしてネイティブ・イメージをビルドします。詳細は、ドキュメントを参照してください。
GDB Python APIに基づいて、Pythonヘルパー・スクリプトgdb-debughelpers.pyを使用してネイティブ実行可能ファイルをデバッグすることができるようになりました。詳細は、ドキュメントを参照してください。
DWARF4からDWARF5にデバッグ情報を更新し、DWARF型単位に型情報を格納するようになりました。DWARF5に切り替えると、デバッグ情報のサイズが30%削減されます。
Windows x64のアンワインド情報の出力のサポートが追加されました。これにより、デバッガやプロファイラなどのネイティブ・ツールでのスタック・ウォーキングが可能になります。

非推奨になった機能

シリアライズJSONメタデータからcustomTargetConstructorClassフィールドを削除しました。シリアライズの型を登録すると、使用可能なすべてのコンストラクタがデフォルトで登録されるようになりました。RuntimeSerialization.registerWithTargetConstructorClassは非推奨になりました。
レガシーのgraal.接頭辞を最初に使用したときに非推奨の警告を表示します。この警告は、JDK 26以降のGraalVMでエラーにアップグレードされます。

ポリグロット・ランタイム

Graal Languageをネイティブ・イメージに埋め込むときに、言語およびインストゥルメント・リソースが自動的に含まれるようになりました。デフォルトでは、イメージの隣に個別のリソース・フォルダが作成されなくなりました。詳細は、言語の埋込みガイドを参照してください。
GraalVM for JDK 24以降、ユーザーは、JDKによって警告が出力されないように、java実行可能ファイルへのネイティブ・アクセス権限を構成する必要があります。モジュールパスを使用する場合は、--enable-native-access=org.graalvm.truffleオプションを渡し、クラスパスを使用する場合は、--enable-native-access=ALL-UNNAMEDオプションを渡して新しい警告を解決します。Truffleは、ロードされたすべての言語およびツールにネイティブ・アクセス機能を自動的に転送するため、これ以上の構成は必要ありません。--illegal-native-access=denyを使用してユーザーがネイティブ・アクセスを拒否した場合、最適化ランタイムのロードは失敗し、フォールバック・ランタイムが使用されます。詳細は、デフォルトの整合性(JEP 472)を参照してください。
ContextおよびEngineは、強く参照されなくなったときに自動的にクローズされるようになりました。到達可能なValueまたはPolyglotExceptionは、関連付けられたContextの到達可能性を維持します。また、Contextは、明示的にアクセスされた場合、またはその内部にアクティブなポリグロット・スレッドが存在する場合、到達可能のままになります。強く到達可能なLanguage、InstrumentまたはContextインスタンスがある場合、Engineは到達可能のままになります。ただし、クローズについてガベージ・コレクションに依存しないことをお薦めします。かわりに、明示的なコンテキストおよびエンジン管理にtry-with-resourcesパターンを使用します。詳細は、GCでの自動クローズに関するドキュメントを参照してください。
Value#as(byte[].class)を使用してゲスト言語バイト・バッファ(Value#hasBufferElements())の内容を新しいバイト配列にコピーする機能が追加されました。この新機能とゲスト・オブジェクトへの配列(Value#hasArrayElements())としてのアクセスの2つの方法が使用可能な場合、新機能が優先されます。
Value.fromByteBasedString(...)およびValue.fromNativeString(...)を使用したRAWバイト配列およびネイティブ・メモリーからの文字列の作成のサポートが追加されました。Value.StringEncodingを指定する必要があります。

変更ログに、更新内容の完全なリストがあります。

GraalJS

いくつかのECMAScript提案を実装しました:
- Error.isError。ECMAScriptステージング・モード(--js.ecmascript-version=staging)で使用できます。
- Math.sumPrecise。ECMAScriptステージング・モード(--js.ecmascript-version=staging)で使用できます。
- Atomics.pause。ECMAScriptステージング・モード(--js.ecmascript-version=staging)で使用できます。
- Promise.try。ECMAScriptステージング・モード(–js.ecmascript-version=staging)で使用できます。
- Uint8Arrayとbase64および16進数の間の相互変換。ECMAScriptステージング・モード(--js.ecmascript-version=staging)で使用できます。
- RegExp.escape。ECMAScriptステージング・モード(--js.ecmascript-version=staging)で使用できます。
- イテレータのシーケンス処理。ECMAScriptステージング・モード(--js.ecmascript-version=staging)で使用できます。
- ソース・フェーズ・インポート。実験的なオプション--js.source-phase-importsを使用すると、使用できます。
- 正規表現パターン修飾子(デフォルトで使用可能)。
WHATWGエンコーディング標準のTextDecoderおよびTextEncoder APIを実装しました。これらは、実験的なオプション--js.text-encodingを使用すると、使用できます。
オプションjs.load、js.print、js.graal-builtin、およびjs.localeが安定版となり、SandboxPolicy.UNTRUSTEDモードで使用できるようになりました。
GraalJSで、import文を介して.wasmモジュールをロードできるWebAssembly/ESモジュール統合がサポートされるようになりました。オプションjs.webassemblyが安定版になりました。

プロジェクト変更ログに、更新内容の完全なリストがあります。

GraalPy

新機能

PythonパッケージのJavaへの埋込みのためにGraalPy Gradleプラグインをリリースしました。
ネイティブ拡張を異なるコンテキストで複数回ロードできるように、実験的なpython.IsolateNativeModulesオプションが追加されました。詳細は、ドキュメントを参照してください。
外部オブジェクトに、その相互運用性に対応するPythonクラスが付与されるようになりました。外部リストはPythonのlistから、外部辞書はdictから、外部文字列はstrから、外部反復子はiteratorから、外部例外はBaseExceptionから、外部数値はpolyglot.ForeignNumberから、外部ブール値はpolyglot.ForeignBooleanから、外部null値はNoneTypeから継承されるようになりました。つまり、これらの型のすべてのPythonメソッドが対応する外部オブジェクトで利用可能になり、可能なかぎりPythonオブジェクトに近い動作をします。Pythonコードで外部オブジェクトに対してメソッドを呼び出すと、Pythonメソッドが外部メンバーよりも優先されるようになりました。また、特定の外部クラスまたは型に対してカスタムPythonメソッドを定義するためのpolyglot.register_interop_typeおよび@polyglot.interop_typeも追加されました。詳細は、ドキュメントを参照してください。

Java埋込みの改善

GraalPy埋込みライブラリ(org.graalvm.python:python-embedding)にKeywordArgumentsおよびPositionalArgumentsという新しい型が導入され、JavaからPythonへキーワードおよび位置引数を直接渡すことがサポートされるようになりました。
org.graalvm.python.embedding.utilパッケージを非推奨にし、対応する新しいパッケージをorg.graalvm.python.embeddingに追加しました。
MavenおよびGradleプラグインは、生成された仮想ファイルシステムにPythonホームを埋め込みません。かわりに、GraalVMネイティブ・イメージ・ビルド用のGraalPyを含む任意のGraal言語の言語ホームの処理は、新しいネイティブ・イメージ・オプション+H:IncludeLanguageResourcesおよび+H:CopyLanguageResourcesによって制御できます。デフォルトでは、Pythonホーム全体がネイティブ実行可能ファイルに埋め込まれます。JVMデプロイメントの場合、言語ホームはMaven CentralのGraalPyアーティファクトに埋め込まれます。

プロジェクト変更ログに、更新内容の完全なリストがあります。

GraalWasm

WebAssemblyモジュールは、import文を介してJavaScriptにロードできるようになりました。GraalJSで、WebAssembly/ESモジュール統合がサポートされるようになりました。詳細は、こちらを参照してください。
Relaxed SIMDの提案を実装しました。この機能は、オプション--wasm.RelaxedSIMDで有効にすることができます。
--wasm.AsyncParsingBinarySizeおよび--wasm.AsyncParsingStackSizeオプションは非推奨になりました。これらのオプションは効果がなくなり、将来のリリースで削除されます。

プロジェクト変更ログに、更新内容の完全なリストがあります。

Espresso

Espresso継続APIの改善: 継続の中断で、生存分析に基づいてスロットがクリアされるようになりました。これにより、取得された変数のセットが予測可能で決定論的になります。
ホスト・コンテキストとEspressoコンテキストの間のよりシームレスな通信を可能にするために、受信ホスト・オブジェクトの汎用型パラメータを自動的に使用するためのサポートが追加されました。
Espressoコンテキストにオブジェクトを渡す際、カスタム型コンバータが組込みコンバータよりも常に優先されるようになりました。
Espressoのハッシュ相互運用実装で、変更不可能なゲスト・マップを変更しようとしたときに、サポートされていない操作例外がスローされるようになりました。
Polyglot.cast()は、Polyglot.castWithGenerics()と同じカスタム型コンバータおよびインタフェース型マッピングを適用するようになりました。
マルチスレッドが無効になっている場合に、<ProcessReferences>組込み関数がハングしなくなりました。

プロジェクト変更ログに、更新内容の完全なリストがあります。

Truffle言語実装フレームワーク

バイトコード・インタプリタを実装するための新しいフレームワークである、実験的なバイトコードDSLを追加しました。バイトコードDSLは、ユーザー指定の操作セットから完全なバイトコード・インタプリタを自動的に生成します。生成されたインタプリタは、命令セット、バイトコード・ジェネレータ、最適化インタプリタなど、バイトコード・インタプリタに必要なすべてのコンポーネントを定義します。バイトコードDSLインタプリタは、ピーク・パフォーマンスを損なうことなく、ASTインタプリタよりフットプリントおよびインタプリタ速度が向上するように設計されています。バイトコードDSLインタプリタは、階層化された解釈、バイトコードの高速化、ボックス化の排除、継続、シリアライズなど、様々な機能をサポートしています。また、インストゥルメンテーションおよびデバッグ用の既存のTruffleツールとも統合されます。開始するには、バイトコードDSLの概要を参照するか、ユーザー・ガイドで詳細を確認してください。バイトコードDSLは、このリリースでは実験的な機能です。
JEP 472: JNIの使用を制限する準備のJavaネイティブ・アクセスが、Truffleによってすべての言語およびツールに自動的に提供されるようになりました。
ホスト言語情報を返すTruffleLanguage.Env.getHostLanguage()メソッドが追加されました。これにより、言語はEnv.getScopeInternal(LanguageInfo)を使用してホスト言語の最上位スコープを参照できます。
@Bind.DefaultExpression注釈を追加しました。デフォルト式では、@Bindパラメータの宣言時に明示的な式を省略できます(パラメータ・タイプのデフォルト式が使用されます)。
コール・ノード、フレームおよびバイトコード索引を指定したインストゥルメンテーションの場所を解決できるRootNode.findInstrumentableCallNode(...)が追加されました。これにより、インストゥルメント可能なノードをバイトコード・インタプリタのサイド・データ構造に格納できます。また、解決された場所にアクセスするために、TruffleStackTraceElement.getInstrumentableLocation()およびFrameInstance.getInstrumentableCallNode()メソッドが追加されました。Truffleインストゥルメンテーション・フレームワークを使用するツールでは、ノードの場所にアクセスするために、かわりにこれらのAPIを使用することが推奨されます。

Truffleの変更ログに、更新内容の完全なリストがあります。