Oracle GraalVM for JDK 24.0.1
(2025-04-15)
これは、Oracle GraalVM for JDK 24用の2025年4月Oracleクリティカル・パッチ・アップデート(CPU)です。このリリースには、2025年4月Oracleクリティカル・パッチ・アップデート・アドバイザで発表されたセキュリティの脆弱性に対する修正が含まれています。これには、そのCPUの一部としてリリースされたセキュリティ修正、次にリストした注目すべきバグ修正、およびプラットフォーム更新が含まれます。
- Oracle GraalVMが構築されているOracle JDKリリースを24.0.1+9に更新しました。JDK 24リリース・ノートを参照してください。
- バージョン互換性:
- Truffle言語および他のコンポーネントのバージョン24.2.1は、GraalVM for JDK 24.0.1で使用するように設計されています。
- Graalコンパイラ
- 修飾されていないエクスポートを
jdk.graal.compilerから削除しました。 rethrowExceptionsのリセット処理をジャンプ・ターゲットの作成時に移動しました。LibGraalCollectionPolicyの最大Edenサイズを構成しました。AMD64ArrayIndexOfOp: 不明な整列の短いジャンプを修正しました。EnterpriseReadElimination:ObjectCloneの処理を修正しました。- ノード照合ルールから浮動小数点CASを生成する場合に、追加の再解釈を省略します。
- 修飾されていないエクスポートを
- ネイティブ・イメージ
- JDK-8345266が採用されました。新しい
MonitorEnterWaitOOME仮想スレッド・テストがJDKにインポートされました。 acquireOnOOMEで正しい取得カウントの使用を実装しました。AMD64ArrayIndexOfOp: 不明な整列の短いジャンプを修正しました。- 特定の定数ロードをスタックに再マテリアライズ可能でないものとしてマークしました。
EnterpriseReadElimination:ObjectCloneの処理を修正しました。- ネイティブ・イメージで定義されたフィールドのみが保持されるように、Mavenで生成されたSBOMからフィールドを削除します。
- セーフポイント・チェック間で存在しないハッシュコード計算が分割されないようにします。
- すべてのSBOMコンポーネントに対してtje
bom-refフィールドが保持されていることを確認します。
- JDK-8345266が採用されました。新しい
- GraalJS
ImportMetaNodeでのコンパイルの失敗を修正しました。WasmInstanceが範囲外の場合にWasmメモリーをクリアするように実装しました。js.webassemblyオプションにCONSTRAINEDサンドボックス・ポリシーを設定します。- オプション
js.text-encodingを安定させ、SandboxPolicy.CONSTRAINEDで許可しました。 - スーパー・プロパティ・アクセスの
ClassCastExceptionを修正しました。
- GraalWasm
WasmFunctionInstanceInteropLibraryでコンパイルの緊急措置を修正しました。- すでにインスタンス化されたWasmモジュールのコード・エントリの再読込みを回避します。
js.webassemblyオプションにCONSTRAINEDサンドボックス・ポリシーを設定します。
- GraalPy
- PyMuPDFのいくつかの修正を追加しました。
- TRegex
- メインの式の境界を越えて水面下のマージを行うための複数の修正を追加しました。
- Truffleフレームワーク
AMD64CodepointIndexToByteIndexOpでの範囲外の読取りを修正しました。- 短絡と組み合わせたブール・ボックス化の排除の修正により、ループが非最適化される可能性があります。
- スレッド・ローカル・アクションが別のスレッドで実行されている間に関連のないスレッドに対して
TruffleSafepoint.poll(...)が実行された場合に、失敗しないように修正しました。 - 戻り型互換性チェックによって、フィルタされる特殊化が無効になる可能性がある場合を修正しました。
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と互換性があります。
機能
- 450: コンパクト・オブジェクト・ヘッダー(実験的)
- 472: JNIの使用を制限する準備
- 475: G1の遅延バリアの拡張
- 478: キー導出関数API(プレビュー)
- 479: Windows 32ビットx86の削除
- 484: クラス・ファイルAPI
- 485: Stream Gatherers
- 486: セキュリティ・マネージャを完全に無効化
- 487: スコープ値(第4プレビュー)
- 488: パターン、instanceofおよびswitchでのプリミティブ型(第2プレビュー)
- 489: ベクターAPI (第9インキュベータ)
- 490: ZGC: 非世代別モードの削除
- 491: ピン留めなしで仮想スレッドを同期
- 492: 柔軟なコンストラクタ本体(第3プレビュー)
- 493: JMODを使用しないランタイム・イメージのリンク
- 494: モジュール・インポート宣言(第2プレビュー)
- 495: 単純なソース・ファイルおよびインスタンスのメイン・メソッド(第4プレビュー)
- 496: 量子耐性モジュール格子ベースのキー・カプセル化メカニズム
- 497: 量子耐性モジュール格子ベースのデジタル署名アルゴリズム
- 498: sun.misc.Unsafeでのメモリー・アクセス・メソッドの使用時の警告
- 499: 構造化同時実行性(第4プレビュー)
- 501: 32ビットx86ポートの非推奨と削除
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を使用すると、使用できます。 - 正規表現パターン修飾子(デフォルトで使用可能)。
- Error.isError。ECMAScriptステージング・モード(
- WHATWGエンコーディング標準の
TextDecoderおよびTextEncoderAPIを実装しました。これらは、実験的なオプション--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の変更ログに、更新内容の完全なリストがあります。