Oracle GraalVM for JDK 20.0.2
(2023-07-18)
これは、Oracle GraalVM for JDK 20用の2023年7月Oracleクリティカル・パッチ・アップデート(CPU)です。このリリースには、2023年7月Oracleクリティカル・パッチ・アップデート・アドバイザで発表されたセキュリティの脆弱性に対する修正が含まれています。これには、そのCPUの一部としてリリースされたセキュリティ修正、次にリストした注目すべきバグ修正、およびプラットフォーム更新が含まれます。
- Oracle GraalVM for JDK 20が20.0.2+9に更新されました。「Java SE 20リリース・ノート」を参照してください
- Graalコンパイラ: オーバーフローするループをストリップ・マイニングしないようにカウントされたストリップ・マイニングの最適化が更新されました。
- ネイティブ・イメージ:
jvmstat
パフォーマンス・データの初期化が修正されました。 - ネイティブ・イメージ: JDK Flight Recorder (JFR)イベント定数プールIDが修正されました。
- ネイティブ・イメージ: 一部のユーザー・エクスペリエンスの問題が修正されました。
- ネイティブ・イメージ: ビルド・レポートの分析結果が修正されました。
Oracle GraalVM for JDK 20.0.1
(2023-06-13)
- プラットフォームの更新
- 非推奨になった機能
- Javaおよびコンパイラの更新
- ネイティブ・イメージ
- JavaScriptおよびNode.js
- ポリグロット埋込み
- Truffle言語およびツールの実装
- Java on Truffle
- Python
- Ruby
- LLVM
- WebAssembly
プラットフォームの更新
- Oracle JDK 20.0.1+8に基づいたOracle GraalVM for JDK 20がリリースされました。「Java SE 20リリース・ノート」を参照してください
- Oracle GraalVMのライセンスは、Oracle JDKと連携されています。Oracle GraalVMは、GraalVM Free Terms and Conditions (GFTC) including License for Early Adopter Versionsに基づいてライセンスされるようになりました。Oracle GraalVMライセンスの詳細は、「Oracle Java SEライセンスに関するFAQ」を参照してください。
- GraalVMパッケージのネーミングを簡素化しました。
graalvm-jdk-<java version>_<platform>-<arch>
です(例: graalvm-jdk-20_macos-aarch64_bin.tar.gz)。 - Oracle GraalVMの新しいダウンロード場所は、Oracle Javaダウンロードです。以前のリリースについては、同じままです。
非推奨になった機能
次の機能およびコンポーネントは非推奨で、GraalVM for JDK 23で削除されます:
- Node.js
- LLVMランタイム
Javaおよびコンパイラの更新
- 低レイテンシが必要なワークロードや非常に大きなヒープ・サイズを使用するワークロードに対するZGCガベージ・コレクタのサポートが追加されました。#2149を参照してください。
- 非投機的モードを追加することにより、オプティミスティックなエイリアス解析が強化されました。(ループのベクトル化が改善されました。)一部のコード・シェイプは、以前はJITでのみベクトル化され、事前コンパイルではベクトル化されませんでした。ネイティブ・イメージのループのベクトル化が改善されたため、これらのコード・シェイプの差異がなくなり、コンパイラはより多くのループをベクトル化して高速に実行できるようになりました。
- 新しい最適化コンパイラ・フェーズのロギングが改善されました。最適化の決定をログおよびダンプ(JSONを使用するなど)するインタフェースが統合されました。最適化フェーズでは、
OptimizationLog
を使用して変換をログに記録する必要があります。OptimizationLog.mdおよびProfdiff.mdで詳細を参照して、ホット・コンパイルで実行された最適化を比較する方法を学習します。 - オープンソースのIdeal Graph Visualizer (IGV)により、サードパーティのコンパイラや言語開発者が使用したり、貢献しやすくなります。詳細は、こちらを参照してください。
更新については、変更ログを参照してください。
ネイティブ・イメージ
パッケージングおよびプラットフォームの更新
- ネイティブ・イメージは、GraalVM for JDK 20の一部として出荷され、
gu install native-image
を介してインストールする必要がなくなりました。詳細は、こちらを参照してください。 - 既知の場所にVisual Studioインストールが見つかった場合、ネイティブ・イメージによってWindows上にビルド環境が自動的に設定されるようになりました。したがって、x64ネイティブ・ツール・コマンド・プロンプトでの実行は必須ではなくなりました。
- LinuxでのAWTライブラリの動的リンクが改善されました。LinuxでのAWTライブラリの静的リンクは、常に問題の原因となっていました。動的リンクでは、スタンドアロン・バイナリをなくして静的リンクで陥りやすい誤りを回避します。これは、WindowsでのAWTサポートによって示されるように、合理的なトレードオフです。リンカーは、「
jvm
の複数の定義」のために失敗したり、LinuxでAWS/Swingアプリケーションのリンク・ステップでクラッシュしたりしなくなります。 - OpenSSL 3.0 FIPS上に実装されたJava暗号化アーキテクチャ(JCA)プロバイダであるJipher JCEは、GraalVMネイティブ・イメージをサポートするようになりました。FIPSで認められたアルゴリズムのみを使用するコンテキストで、ネイティブ・イメージを使用するJipherを有効にすることをお薦めします。まず、ドキュメントを参照してください。
新機能
- 自己完結型バンドルからネイティブ実行可能ファイルをオンデマンドでビルドする新機能が導入されました。新しいオプション
--bundle-create=<imagename>.nib
は、<imagename>.nibファイル(ビルド・バンドル)およびlaunch.outputディレクトリとネイティブ実行可能ファイルを作成します。バンドル・ファイル<imagename>.nibは、ネイティブ実行可能ファイル(またはネイティブ共有ライブラリ)のビルドに必要なすべての情報を含む通常のJARファイルです。通常のnative-image
ビルドとは対照的に、この操作モードは入力として1つの*.nibファイルのみを取ります。後で同じバージョンのGraalVMが使用された場合、実行可能ファイルは次を使用して再ビルドできます:native-image --bundle-apply=.../path/to/launch.nib
最初のビルドと同じイメージ引数、環境変数、システム・プロパティ、クラスパスおよびモジュールパス・オプションを使用して、ネイティブ実行可能ファイルを再ビルドします。これは、ビルドに必要なすべての入力を単一のファイルにカプセル化する、安全で信頼性の高いソリューションです。詳細は、ネイティブ・イメージ・バンドルのリファレンス・マニュアルを参照してください。
- ネイティブ・イメージ・ビルド・プロセスのメモリー・フットプリントが改善されました。ビルダーは、同じマシン上で他の多くのプロセスが実行されている場合に、メモリー負荷を軽減するために使用可能なメモリーを考慮に入れるようになりました。また、多くの場合、消費されるメモリーが少なくなるため、メモリー不足エラーで失敗する可能性も低くなります。同時に、メモリー制限が14GBから32GBに増加しました。
- ネイティブ・イメージは、デフォルトでAMD64のx86-64-v3アーキテクチャをターゲットとし、ターゲットの互換性を指定する新しい
-march
オプションを提供します。ネイティブ実行可能ファイルが同じマシンまたは同じCPU機能を持つマシンにデプロイされる場合、最高の互換性のために-march=compatibility
を使用するか、最高のパフォーマンスを得るために-march=native
を使用します。使用可能なすべてのマシン・タイプをリストするには、-march=list
を使用します。 - ネイティブ・イメージで欠落しているメタデータのレポートが改善され、特別な例外がスローされるようになりました。ネイティブ・イメージは、到達可能性メタデータの欠落と、リフレクションAPIによってスローされた例外を区別しません。たとえば、クラスがクラスパス上にない場合、またはクラスのメタデータが存在しない場合にスローされる
ClassNotFoundException
です。ネイティブ・イメージ・ユーザーは、オプション-XX:ExitOnMissingMetadata
を使用してメタデータ例外を捕捉し、プログラムをデバッグして、すべてのメタデータ・エントリが正しいことを保証できるようになりました。詳細は、こちらを参照してください。これは試験的機能であり、デフォルトではオンになっていません。 - ネイティブ・イメージにおいてリフレクションおよびリソース・メタデータの安全な構成が導入されました。たとえば、
java.lang.Class#getDeclaredMethodsreturn
などのリフレクティブ・メソッドは、他のリフレクティブ要素の到達可能性に基づきます。新しいメタデータを追加すると、到達可能な要素が増え、プログラムの機能が変わる可能性があります。メタデータ最適化の安全な構成により、native-image
ビルダーでは、java.lang.Class
に対するすべてのリフレクティブ・コールにメタデータ・エントリが必要であることが保証されるようになりました。詳細は、こちらを参照してください。 - 引数なしの
--initialize-at-build-time
オプションは使用できなくなりました。一時的な回避策として、-H:+AllowDeprecatedInitializeAllClassesAtBuildTime
オプションを使用すると、このエラーが警告に変わります。 - LLVMバックエンドを介したネイティブ・イメージ用の試験的なRISC-Vモードが追加されました。詳細は、このブログ投稿を参照してください。
- ネイティブ・イメージにおけるプロファイルに基づく最適化(PGO)が改善されました:
- プロファイルに基づく最適化に、コール・スタックを定期的に収集する新しいサンプリング・プロファイラが追加されました。サンプリング・プロファイラをオンにしてコール・スタックを収集するには、オプション
--pgo-sampling
を使用します。このデータは、.iprofファイルに含まれます。PGOでインストゥルメントされた実行可能ファイルがビルドされると、サンプリング・プロファイラはデフォルトでオンになります(ただし、オプション-H:-SamplingCollect
でオフにできます)。良好なプロファイル、ひいては良好なピーク・パフォーマンスを得るには、関連するワークロードを実行し、アプリケーションを適切にウォームアップする必要があります。 - "ホット"コード内のプロファイルのサンプリングに特化し、ホット・コンパイル・ユニットにより多くの最適化作業を投じるContext-Aware Inliner (CAI)最適化が実装されました。最適化されたイメージがPGO用にビルドされると、Context-Aware Inlinerが自動的にオンになります(ただし、オプション
-H:-AOTInliner
でオフにできます)。その結果、実行可能ファイルのサイズは2-7%小さくなり、ピーク・パフォーマンスが向上します。 - プロファイルのマージが改善され、事前にパッケージ化されたプロファイルが有効になりました。
- プロファイルに基づく最適化に、コール・スタックを定期的に収集する新しいサンプリング・プロファイラが追加されました。サンプリング・プロファイラをオンにしてコール・スタックを収集するには、オプション
- 機械学習(ML)ベースのプロファイル推論が追加されました。プロファイリングが無効になっている場合、ネイティブ・イメージのGraalコンパイラでは、事前にトレーニングされたMLモデルを使用して、制御分割ブランチのプロファイルを推論します。その後、推論されたプロファイルを使用して、プロファイルに基づく最適化が実行されます。Renaissance、Da Capo、Da Capo con Scalaなどの一部のベンチマークでは、この最適化によって、デフォルトのOracle GraalVM構成と比較してランタイム速度が最大6%向上します。ネイティブ実行可能ファイルのビルドをMLプロファイル推論で実行すると、バイナリ・サイズがわずかに(1%-2%)増加することが予想されます。この最適化は、Oracle GraalVMではデフォルトで有効になっています。無効にするには、
-H:-MLProfileInference
オプションを使用します。 - ネイティブ・イメージのSBOMに、ランタイム・コンポーネント用の単一のSBOMコンポーネントが含まれるようになりました。このコンポーネントは、実行可能ファイルの
java.vm.version
プロパティを使用してバージョンを識別し、新しいgraalvm-native-image
製品に属します。
ビルド出力の改善
- ビルダーは、実行可能ファイルの内容をよりよく理解するのに役立つビルド・レポートを生成できるようになりました。
-H:+BuildReport
を使用して、この新しい試験的機能を試してください。 - 内部エラーのレポートが改善され、よりユーザーフレンドリになりました。明確なメッセージにより、ユーザーがどのように処理を進めればよいかが示されます。エラー・レポートを検査し、問題を解決できない場合は、エラー・レポートを添えてイシューを作成します。HotSpotにならって、エラー・レポートのデフォルトのファイル名は./svm_err_b_<timestamp>_pid<pid>.mdです。また、新しいオプション
-H:ErrorFile
が追加され、エラー・レポートに別のファイル名を選択できます。#5414を参照してください。 native-image
ビルド出力が調整されて、クラスではなくタイプ(プリミティブ、クラス、インタフェースおよび配列)をレポートするようになり、-H:BuildOutputJSONFile
の出力スキーマが修正されました。native-image --version
コマンドの出力および様々なJavaプロパティ(java.vm.version
など)は、OpenJDKに合せて調整されています。GraalVM Community Edition、Oracle GraalVMおよびGraalVMディストリビューションを他のベンダーと区別するには、java.vm.vendor
を参照してください。
デバッグおよびモニタリング・エクスペリエンスの改善
- 引数なしでオプション
--enable-monitoring
を使用することは非推奨になりました。このオプションは、デフォルトでall
に設定されなくなりました。かわりに、有効にするモニター機能のリストを常に明示的に指定します(例:--enable-monitoring=heapdump,jfr,jvmstat
)。 - ヒープ・ダンプが作成される場所を制御するオプション
-XX:HeapDumpPath
が追加されました。 - アプリケーション・モニタリング用のJFRイベント(
ExecutionSample
、ObjectAllocationInNewTLAB
およびJavaMonitorInflate
)が追加されました。 - Windowsでのデバッグが改善されました。デバッグ情報にJavaタイプに関する情報が含まれるようになりました。(Red Hatと共同。)
- JMXを介したリモート管理がネイティブ・イメージに実装されました。これは、オプション
--enable-monitoring
で有効にできます(例:--enable-monitoring=jmxclient,jmxserver
)。詳細は、こちらを参照してください。この機能は試験段階です。(Red Hatと共同。) - ネイティブ・イメージのJFRイベント・ストリーミングが可能になりました。この機能は試験段階です。(Red Hatと共同。)
その他の更新については、ネイティブ・イメージの変更ログを参照してください。
JavaScriptおよびNode.js
- Node.jsがバージョン18.14.1に更新されました。
BigInteger
相互運用性サポートが追加されました。外部BigIntegers
では、JSBigInt
セマンティクスを選択するために、BigInt
関数を使用した明示的な型キャストが必要です。デフォルトのセマンティクスは、元の値や型に関係なく、すべての外部数値をJavaScriptNumber
値のように扱います。算術演算子はdoubleへの暗黙的な非可逆変換を行います。比較演算子では、可能なかぎり正確な値の比較が試行されます。JavaScriptBigInt
値をjava.math.BigInteger
ホスト・オブジェクトに変換できるようになりましたが、ターゲットの型があいまいまたは存在しない場合は、一貫性のある型マッピングを確保するためにターゲットの型のマッピングが必要になる場合があります。- GraalVM JavaScriptランタイムにいくつかの新しいECMAScript提案が実装されました:
- イテレータ・ヘルパーの提案。試験段階のオプション
--js.iterator-helpers
で使用可能になります。 - ShadowRealm APIの提案。試験段階のオプション
--js.shadow-realm
で使用可能になります。 - WeakMapキーとしてのシンボルの提案。ECMAScriptステージング・モード(
--js.ecmascript-version=staging
)で使用できます。 ArrayBuffer.prototype.transfer
などの提案。ECMAScriptステージング・モード(--js.ecmascript-version=staging
)で使用できます。- コピーによる配列の変更の提案。ECMAScriptステージング・モード(
--js.ecmascript-version=staging
)で使用できます。
- イテレータ・ヘルパーの提案。試験段階のオプション
ノート: Node.jsサポートは非推奨としてマークされており、将来のリリースで削除されます。
その他の更新については、プロジェクトの変更ログを参照してください。
ポリグロット埋込み
- 今リリースは、コード・サンドボックスでの信頼できないアプリケーションの実行をサポートする最初のリリースです。4つの異なるサンドボックスのレベル(
ISOLATED
、UNTRUSTED
、TRUSTED
、およびCONSTRAINED
)を持つサンドボックス・ポリシーContext.Builder#sandbox(SandboxPolicy)
が実装され、ユーザーがホスト・アプリケーションとゲスト・コードの間にセキュリティの境界を確立できるようになりました。ポリシーは、Engine.Builder#sandbox(SandboxPolicy)
またはContext.Builder#sandbox(SandboxPolicy)
ビルダー・メソッドに渡すことによって設定されます。ホスト・コードは、UNTRUSTEDポリシーなどを使用して、信頼できないゲスト・コードを実行できます。ホスト・コードは、相互に保護されるゲスト・コードの相互に信頼されないインスタンスを複数実行できます。詳細は、ポリグロット・サンドボックス化のガイドを参照してください。コード・サンドボックスは現在、Javascriptでのみサポートされています。 - コード・サンドボックス実装に関連して、ゲスト・アプリケーションのリソース消費を測定し、現実的なサンドボックス・パラメータを取得するための新しいオプション
TraceLimits
が追加されました。 IOAccess
API(多言語コンテキストのIOアクセス構成)が追加されました。IOアクセス構成によって、ゲスト言語がホストIOにアクセスする方法が決まります。新しいIOAccess
クラスは、ホストIOアクセスを無効にしたり、フル・ホストIOアクセスを有効にするための事前定義済の構成を提供します。カスタム構成は、IOAccess
ビルダーを使用して作成できます。- ポリグロット値APIに
java.lang.BigInteger
が追加されました。デフォルトでは、java.lang.BigInteger
型のすべてのホスト値は以前とは異なり数値(Value.isNumber()
)として解釈されるようになりました。以前の動作に戻すには、HostAccess.Builder.allowBigIntegerNumberAccess(boolean)
をfalse
に設定します。長い値に収まらない数値を解釈するための言語サポートは異なる場合があります。JavaScriptなどの一部の言語では、ホストの大整数を明示的に変換する必要がある場合があります。RubyやPythonなどのその他の言語では、明示的な変換を行わずに大整数を使用できます。同じことが、ゲスト言語間で渡される値にも当てはまります。#2737を参照してください。 - ネイティブ・イメージにTruffle言語を埋め込むための言語リソースの自動コピーが追加されました。ドキュメントはこちらで提供されています。
変更の完全なリストは、changelogを参照してください。
Truffle言語およびツールの実装
- パフォーマンス向上のため、Truffle DSLにいくつかの新機能が実装されました。特に、Truffleノードを自動的にオブジェクト・インライン化できる
@GenerateInline
という新しい注釈が導入されました。オブジェクトがインライン化されたTruffleノードはシングルトンになるため、メモリー・フットプリントを削減します。これは、キャッシュされたノード・バージョンまたはキャッシュされていないノード・バージョンを生成する@GenerateCached
および@GenerateUncached
と同様に機能します。詳細は、ドキュメントを参照してください。
パフォーマンス向上に寄与するその他の更新は次のとおりです:
- 更新されたTruffle DSLノードは、特殊化中にノードのロックが不要になり、初回実行パフォーマンスが向上しました。CASスタイルのインライン・キャッシュ更新は、ガードで
CallTarget.call(...)
をコールするときにデッドロックを回避するために使用されるようになりました。インライン・キャッシュは重複値がないことを保証し続け、競合状態の影響を受けません。言語の実装では、競合が減少すると、言語の他のスレッドセーフティの問題が明らかになる可能性があることに注意してください。 - 生成された状態用のフィールドをマージし、ビット・セットを除外し、特殊化データ・クラスの生成を改善してアクティブ化の見込みを考慮することで、Truffle DSLノードのメモリー・フットプリントが改善されました。最適な結果を得るには、特殊化をアクティブ化の見込みに従って順序付けする必要があります。
- 列挙型のキャッシュされたパラメータ値を状態ビットセットに自動的にインライン化することで、メモリー・フットプリントが改善されました。
- Truffle DSLは、推奨事項についてさらに多くの警告を発するようになりました。たとえば、インライン化の機会、キャッシュ共有、またはキャッシュ・イニシャライザを
@NeverDefault
として指定する必要がある場合に警告を発します。移行作業を容易にするために、Javaパッケージの警告を一時的に抑制する新しい方法が追加されました。考えられる警告のリストと詳細な使用方法については、ドキュメントを参照してください。 - 閉じられていないポリグロット・エンジンは、VMの停止時に自動的に閉じられなくなりました。VMとともに終了します。その結果、VMが停止した場合、
TruffleInstrument#onDispose
は閉じられていないエンジンでアクティブなインストゥルメントに対してコールされません。インストゥルメントが廃棄前に特定のアクション(たとえば、ある種のサマリーの出力)を行うことになっている場合、TruffleInstrument#onFinalize
で実行するようにしてください。 - コード・サンドボックスの制限を制御するポリシーが実装されました。デフォルトでは、言語およびインストゥルメントは
TRUSTED
サンドボックス・ポリシーのみをサポートします。- 言語でより限定的なサンドボックス・ポリシーのターゲットを指定する場合は、次のことが必要です:
TruffleLanguage.Registration#sandbox()
を使用して、必要とする最も厳格なサンドボックス・ポリシーを指定します。- 各オプションについて、言語は、
Option#sandbox()
を介してオプションを使用できる最も制限の厳しいサンドボックス・ポリシーを指定する必要があります。デフォルトでは、オプションはTRUSTED
サンドボックス・ポリシーを持ちます。 - 言語に追加の検証が必要な場合は、
TruffleLanguage.Env#getSandboxPolicy()
を使用して現在のコンテキスト・サンドボックス・ポリシーを取得できます。
- インストゥルメントでより制限的なサンドボックス・ポリシーをターゲットにする場合は、次のことを行う必要があります:
TruffleInstrument.Registration#sandbox()
を使用して、必要とする最も厳格なサンドボックス・ポリシーを指定します。- 各オプションについて、インストゥルメントは、
Option#sandbox()
を介してオプションを使用できる最も制限の厳しいサンドボックス・ポリシーを指定する必要があります。デフォルトでは、オプションはTRUSTED
サンドボックス・ポリシーを持ちます。 - インストゥルメントに追加の検証が必要な場合は、
TruffleInstrument.Env#getSandboxPolicy()
を使用してエンジンのサンドボックス・ポリシーを取得できます。
- 言語でより限定的なサンドボックス・ポリシーのターゲットを指定する場合は、次のことが必要です:
その他の更新については、Truffleの変更ログを参照してください。
Java on Truffle (Espresso)
新機能:
- Truffle InteropLibrary
has/getMetaParents
APIが完全に実装されました。 - interopを介して
espresso
をコールすると、外部Instant
、TimeZone
、Time
、Date
、Duration
が有効になります。
改善:
- interopを介してオーバーロード・メソッドおよびVarargsメソッドをコールできるようになりました。
- 外部例外との相互運用性が改善されました。スタック・トレースが使用可能になり、型マッピングを使用して例外を明示的にマップできるようになりました。
Python
パフォーマンスの向上:
- デフォルトでは完全ネイティブ実行を使用するPython C APIインタフェースの新しい実装が追加されました。これにより、ネイティブ・コードに多くの時間を費やす一部の拡張機能(SciPy、PyTorchなど)とのパフォーマンスおよび互換性が向上しますが、Python/ネイティブ境界を頻繁に越えるワークロードに悪影響を及ぼす可能性があります。拡張機能のビルドおよび実行方法を制御する新しいオプション
python.NativeModules
およびpython.UseSystemToolchain
があります。新しいデフォルトでは、GraalVMに付属しているLLVMツールチェーンではなく、ホスト・システムのツールチェーンを使用して拡張機能をビルドし、すべてのモジュールをネイティブで実行します。古い動作を取得するために新しいランチャ(graalpy-lt
)を使用できます。これはデバッグに役立ちます。 - Webサイトで報告されるパフォーマンス数値は、コミュニティの
pyperformance
ベンチマーク・スイートの結果に基づいており、CPythonやJythonに対するGraalPyの幾何平均速度向上が測定されています。これにより、結果の比較と再現が容易になります。
プラットフォームの更新:
- Windowsでの基本的なGraalPyワークロードのビルドおよび実行が実装されました。これにより、Windowsユーザーは、特にJavaへの埋込み用にGraalPyをビルドして使用できます。
- 組込みモジュールとしてVirtualenvのGraalPyプラグインが追加されたため、GraalPyで
virtualenv
を使用した仮想環境の作成がすぐに機能できるようになりました。 - ベースGraalPyに委任される生成されたシェル・スクリプトではなく、シンボリック・リンクを使用して仮想環境を作成するように、組込みの
venv
モジュールが更新されました。
互換性の向上:
- 言語バージョンおよび標準ライブラリが3.10.8に更新され、最新のモジュールおよびパッケージと互換性を持つようになりました。
- CPythonと一致するようにGraalPyのディストリビューション・レイアウトが更新されました。これにより、GraalPyのライブラリの場所を検出するために様々なビルド・システムに必要なパッチの数が削減されます。
numpy
およびpandas
バージョンが更新されました。scipy
およびscikit_learn
がginstall
で実装されるようになりました。
更新の完全なリストは、プロジェクトの変更ログを参照してください。
Ruby
新機能:
- Ruby 3.1.3に更新されました。
- 外部の大整数がサポートされるようになり、すべての
Numeric
演算子を使用できます。
パフォーマンス:
- YAMLを解析するときのウォームアップを改善するために、
psych
用のシステムlibyaml
が使用されるようになりました。つまり、libyaml
は依存関係になりました。LibYAMLのインストール方法を参照してください。 - オブジェクトにラップされたネイティブ構造のマーキングは、メモリーのオーバーヘッドを削減するために、C呼出しの終了時に行われるようになりました。
cloneUninitialized()
を実装することで、コール・ターゲットの分割(コピー)が最適化されました。Process.pid
は、$$
のようにプロセスごとにキャッシュされるようになりました。- 特定のコール・サイトでの複数のコールで増大する
Array
を構築するメソッドの繰返し脱最適化が修正されました。
バグの修正:
- macOSでの
spawn(..., fd => fd)
が修正されました。macOSのバグが原因で機能しませんでした。 rb_gc_register_address()
/rb_global_variable()
が最新の値を読み取るように修正されました(#2721、#2734を参照)。
変更の完全なリストは、プロジェクトの変更ログを参照してください。
LLVM
- LLVMツールチェーンがバージョン15.0.6に更新されました。
musl libc
がバージョン1.2.3に更新されました。- LinuxのAArch64アーキテクチャに
long double
(128ビット浮動小数点)が実装されました。
ノート: LLVMランタイム・サポートは非推奨としてマークされており、将来のリリースで削除されます。