Pull Request on 2026年08月31日

dotnet/runtimeにマージされたPull RequestをAIで日本語要約

注意点

このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。



#132976 [release/11.0] Align CoreCLR GS cookie protection with NativeAOT

概要

CoreCLR のGS(Guard Stack)cookie保護メカニズムをNativeAOTと統一するバックポート。本変更は#132925をrelease/11.0ブランチにバックポートするもので、スタックオーバーフロー攻撃対策の実装を両ランタイム間で統一することを目的としています。

変更内容

  • src/coreclr/vm/CMakeLists.txt: ビルド設定を4行追加
  • src/coreclr/vm/ceemain.cpp: ランタイム初期化時のGS cookie処理を4行追加
  • src/coreclr/vm/vars.cpp: GS cookie関連コードを4行追加
  • src/coreclr/vm/vars.hpp: GS cookie定義/宣言を6行追加(既存の1行を置き換え)

変更は CoreCLR ランタイムの内部実装(src/coreclr/vm/)に限定され、公開APIへの影響はありません。

パフォーマンスへの影響

影響なし(セキュリティ機能の統一化であり、パフォーマンスへの直接的な影響は想定されていません)

関連Issue

#132925

その他

  • 本PRはbackport指定のため、元のPR(#132925)の詳細なテスト結果やリスク評価はそちらを参照してください
  • .NET 11.0のrelease branchへのバックポート案件です

#132963 [LoongArch64] Fix the GCReg update for the relocation case (pcalau12i + addi.d/ld.d) of NativeAOT, the GCReg should update after calculation completed.

概要

LoongArch64プラットフォーム上のNativeAOTにおいて、pcalau12i + addi.d/ld.d命令のリロケーションケースでGCRegの更新タイミングが誤っていた問題を修正します。GCRegは計算完了後に更新される必要があります。この修正により、NativeAOTテストSmokeTests/DynamicGenericsの間欠的なGCクラッシュが解決されます。

変更内容

  • src/coreclr/jit/codegenloongarch64.cpp: GCReg更新ロジックを修正(+5行、-2行)
  • src/coreclr/jit/emitloongarch64.cpp: リロケーション処理のGCReg更新タイミングを修正(+11行)

変更は、LoongArch64コードジェネレータとエミッタにおいて、GCレジスタ追跡のタイミングを正確にするもので、メモリアドレス計算(pcalau12i命令による上位12ビット設定の後、addi.dまたはld.d命令による下位ビット設定)の完了後にGCReg状態を更新するように修正されています。

パフォーマンスへの影響

影響なし(バグ修正のため、パフォーマンス改善ではなく、正確性の改善)

関連Issue

#132963

その他

  • LoongArch64プラットフォーム固有の修正のため、他のアーキテクチャには影響しません
  • この修正はNativeAOTのランタイムレイヤー(JIT/エミッタ)に関する内部実装の修正です

#132958 Delete flaky GcRestrictedCalloutReversePInvoke test

  • 作成者: @Copilot
  • 作成日時: 2026年08月31日 04:19:39(UTC)
  • マージ日時: 2026年08月31日 22:16:08(UTC)
  • ラベル: area-Interop-coreclr

概要

不安定な動作が報告されていた GcRestrictedCalloutReversePInvoke テストを削除します。このテストはCOM/ComWrappersの相互運用性を検証するもので、タイムアウトによるGen2ガベージコレクション待機時の失敗が既知の問題でした。

変更内容

  • src/tests/Interop/COM/ComWrappers/GcRestrictedCalloutReversePInvoke/Program.cs を削除(128行)
  • src/tests/Interop/COM/ComWrappers/GcRestrictedCalloutReversePInvoke/GcRestrictedCalloutReversePInvoke.csproj を削除(21行)
  • テストプロジェクト全体が削除され、ビルド・実行の対象外になります

パフォーマンスへの影響

テスト実行時間の短縮(不安定なテストの削除による)。ランタイムの機能に影響なし。

関連Issue

#132939(削除対象Issue) #130459(初期実装PR)

その他

PR作成者(Copilot)は、当初からこのテストの必要性に疑問を持っており、フレーキーな動作が判明したことで削除の判断が明確になったとコメントしています。リポジトリ内に削除テストへの残存参照がないことを確認済みです。


#132933 Reduce COFF relocation allocation overhead

概要

NativeAOT のCOFF リロケーション処理におけるメモリ割り当てオーバーヘッドを削減します。CoffRelocationをヒープオブジェクトから12バイトの不変値型構造体に変更し、リロケーション列挙時にref readonlyで反復処理することで、数千万のリロケーションレコード処理時のメモリ使用量とGC圧力を大幅に軽減します。

変更内容

  • CoffObjectWriter.cs: CoffRelocationをクラスからinternal readonly structに変更。VirtualAddress、SymbolTableIndex、Typeフィールドを保持し、12バイトのマネージレイアウトでList<CoffRelocation>に格納。Writeメソッドは引き続き10バイトのCOFF形式を出力。リロケーション発行時にCollectionsMarshal.AsSpanとref readonly反復を使用してディフェンシブコピーを回避。
  • テスト追加: CoffObjectWriterTests.csでリロケーションエンコーディング、オーバーフロー記録動作、アーキテクチャ別リロケーションタイプマッピングを検証。

パフォーマンスへの影響

ベンチマーク結果(500万リロケーション処理):

  • マネージメモリ割り当て: -92.9 MiB (-31.57%)
  • ヒープリロケーションオブジェクト: 500万個 → 0個
  • Gen 0/1/2 GC収集回数: 各-11/-11/-3回
  • ピークプライベートバイト: -93.0 MiB
  • ピークワーキングセット: -127.9 MiB
  • リロケーション変換時間: -83.47% (487.66ms → 80.60ms)

実RDM実績(4,100万リロケーションレコード):

  • マネージメモリ割り当て: 0.51~0.67 GiB削減
  • 出力ファイル: 同一SHA-256ハッシュで3.7 GiB

改善点は割り当てとオブジェクト密度。エンドツーエンドのコンパイル時間改善は確認されていません。

関連Issue

なし

その他

  • 内部実装の変更で、公開APIへの影響なし
  • 既存のCOFF形式互換性を保証(10バイトのワイヤエンコーディング変更なし)
  • Writeメソッドがreadonlyマークされていないため、ref readonly反復でディフェンシブコピーが発生する可能性がありレビュー指摘あり
  • ビルド検証済み(clr.aot+libs、ILCompiler.Compiler.Tests 22/22合格、NativeAOT smoke tests 28/28合格)

#132931 Avoid slow parallel connect failures in SocketAsyncEventArgs test

概要

SocketAsyncEventArgsTest.Connect_Parallel_FailsテストがmacOSで30秒のタイムアウトを超える問題を修正。バインドされているが待機していないソケットへの接続がmacOSで保留状態のままになる代わりに、テストスイートの予約済み未使用ポートを使用することで、OS依存の遅い動作を回避しながら並列IPv4/IPv6接続エラーをテストしています。

変更内容

  • SocketAsyncEventArgsTest.cs:Connect_Parallel_Failsテストを修正
    • バインド済み非待機ソケット + PortBlockerの設定を削除
    • DualModeBase.UnusedPortを使用した予測可能な「接続拒否」エラーに変更
    • Socket.ConnectAsync呼び出しを簡素化(SocketType.Stream/ProtocolType.Tcp定数を直接使用)

パフォーマンスへの影響

大幅な改善: macOS ARM64で測定した結果、修正前後で以下の改善を確認

  • 修正前:テストあたり約8~19秒(OS依存の潜在的遅延あり)
  • 修正後:テストあたり約43~101ミリ秒(約100倍以上の高速化)
  • 2500個のSystem.Net.Sockets機能テスト全体も合格確認済み

関連Issue

#132059

その他

  • 本修正はテスト実装の改善であり、ランタイムやパブリックAPIへの変更はなし
  • macOSでのテスト不安定性を解消し、CI/CDパイプラインの信頼性向上に寄与
  • Helix環境での複数実行検証が完了(50回連続合格)

#132925 Align CoreCLR GS cookie protection with NativeAOT

  • 作成者: @steveisok
  • 作成日時: 2026年08月29日 18:33:13(UTC)
  • マージ日時: 2026年08月31日 17:44:39(UTC)
  • ラベル: area-VM-coreclr

概要

CoreCLRのGS Cookie保護をNativeAOTに合わせて調整し、Apple macOS arm64でLLDB内部でのホストが失敗する問題(coreclr_initializeが0x8007000Cを返す)を修正します。Apple、WebAssembly、OpenBSDでは読み取り専用ページ保護機能を無効化し、これらのプラットフォームの不変セグメント制限に対応します。

変更内容

  • CMakeLists.txt: FEATURE_READONLY_GS_COOKIEフラグを定義し、Apple・WebAssembly・OpenBSDを除く全プラットフォームで有効化
  • vars.hpp: s_gsCookieの宣言をフラグに応じて条件付きに変更(有効時はconst/READONLY_ATTRで読み取り専用、無効時は通常の書き込み可能データ)
  • vars.cpp: s_gsCookieの定義を条件付きに変更し、ヘッダの宣言と一致させる
  • ceemain.cpp: InitGSCookie()のClrVirtualProtect呼び出しをFEATURE_READONLY_GS_COOKIEで条件付きガード

パフォーマンスへの影響

影響なし。WebAssemblyではページ保護オーバーヘッドを削減。Cookie生成と書き込みロジック自体は全プラットフォームで変化なし。

関連Issue

#99977、#99173(NativeAOT関連)

その他

互換性への影響: Apple・WebAssembly・OpenBSDでは防御層が削減されますが、これらのプラットフォームでの互換性と安定性を優先。他のプラットフォームは既存の読み取り専用Cookie動作を維持。

検証: macOS binary上でs_gsCookieが__DATA,__common(書き込み可能)に配置されることを確認。LLDBでの動作テストで修正前の失敗(0x8007000C)から修正後の成功(S_OK)に改善。SOS test harness(diagnostics)でのエンドツーエンド検証済み。


#132921 Preserve side effects in SIMD classification helpers

概要

SIMD分類ヘルパー関数(IsInfinityなど)がコンパイル時に定数にフォールドされる際に、オペランドの副作用(例外など)が失われる問題を修正しました。9つの分類操作すべてが対象です。Vector128.WithElementの例外生成オペランドを使用した回帰テストを追加し、x64とWASMの共有インポート形状をカバーしています。

変更内容

  • src/coreclr/jit/gentree.cpp: SIMD分類ヘルパーで定数にフォールドする際に、オペランドから抽出した副作用をラップすることで、例外やメソッド呼び出しが削除されることを防止
  • src/tests/JIT/Regression/JitBlue/Runtime_132902/Runtime_132902.cs: 9つの分類操作にわたってオペランドの例外が保持されることを検証する回帰テストを新規追加
  • src/tests/JIT/Regression/Regression_ro_2.csproj: 新規回帰テストをJIT回帰テストプロジェクトに登録

パフォーマンスへの影響

影響なし。この修正は定数フォールディング時に副作用を保持する仕組みを追加するもので、コンパイル時の最適化レベルを変更しません。

関連Issue

#132902

その他

なし


#132907 [release/10.0] Fix internal Helix queue selection

概要

release/10.0ブランチにおいて、内部ビルドで約2,000件のエラーが発生していた問題を修正します。Ubuntu AndroidキューをAndroidとBionicプラットフォームのみに制限し、内部検証時に非Android/BionicのライブラリワークアイテムがAndroidエージェントで実行されるのを防ぎます。

変更内容

  • eng/pipelines/libraries/helix-queues-setup.yml: Ubuntu Androidキューの選択条件を分割し、Android/Bionicプラットフォーム向けのみに限定。arm/arm64の場合、公開ビルドではWindows Androidキューを使用し、内部検証ではUbuntu Androidキューを使用する既存の動作は維持。

パフォーマンスへの影響

影響なし。(この変更はビルドインフラの設定調整であり、ランタイムやコンパイラのパフォーマンスには直接影響しません)

関連Issue

#125548(release/11.0で同様の修正が実施済み)

その他

  • この修正はrelease/11.0で既に適用されている対策をrelease/10.0にバックポートするものです
  • Helix(テスト実行基盤)のキュー選択ロジックに関する内部設定の変更です

#132889 Add R2R knob to force value of TargetAllowsRuntimeCodeGeneration

  • 作成者: @BrzVlad
  • 作成日時: 2026年08月28日 14:31:05(UTC)
  • マージ日時: 2026年08月31日 05:29:14(UTC)
  • ラベル: area-ReadyToRun

概要

Read-Ahead (R2R) コンパイルにおいて、--target-allows-runtime-code-generation オプションを追加し、ランタイムコード生成を強制的に無効化できるようにしました。これにより iOS のような動的コード生成が禁止される環境の設定をシミュレートできます。ランタイムが dynamiccodecompiled false でビルドされた場合、corelib も同じ設定でビルドされるようになり、corerun と testhost がこの設定を確実に遵守します。

変更内容

  • src/coreclr/crossgen-corelib.proj: FeatureDynamicCodeCompiled プロパティに基づいて CrossGen2 に --target-allows-runtime-code-generation オプションを渡すロジックを追加
  • src/coreclr/tools/aot/crossgen2/Crossgen2RootCommand.cs: 新しい --target-allows-runtime-code-generation コマンドラインオプションを追加(bool 型)
  • src/coreclr/tools/aot/crossgen2/Program.cs: オプション引数の処理を追加
  • src/coreclr/tools/aot/crossgen2/Properties/Resources.resx: 新しいオプションのヘルプテキスト・エラーメッセージを追加

パフォーマンスへの影響

影響なし

関連Issue

#130622(FEATURE_DYNAMIC_CODE_COMPILED ハック削除による回帰)の修正

その他

Copilot レビューから指摘されている懸念事項:$(FeatureDynamicCodeCompiled) プロパティがビルド内で真偽値的に扱われている一方、crossgen2 コマンドライン引数に生値で渡されています。プロパティが 0 など "true" 以外の値に設定された場合、引数パース失敗の可能性があります。プロパティを明示的な true/false トークンに正規化してからコマンドラインに渡すことが推奨されています。


#132796 [EventPipe] Add non-lossy Block-mode functional tests

  • 作成者: @mdh1418
  • 作成日時: 2026年08月26日 20:07:56(UTC)
  • マージ日時: 2026年08月31日 18:13:40(UTC)
  • ラベル: area-Tracing-coreclr

概要

EventPipeの非ロッシーBlockバッファリングモード向けのエンドツーエンド機能テストカバレッジを追加します。vendored診断クライアント(Microsoft.Diagnostics.NETCore.Client)とIpcTraceTestインフラストラクチャをdotnet/diagnosticsと再同期し、CollectTracing3~6プロトコル、バッファリングモード選択、イベント損失検証機能に対応させています。

変更内容

  • 新規テストプロジェクト:

    • nonlossyblock(IPC経由):無効なバッファリングモード拒否、1MBバッファでBlock モード開始、4つの並行プロデューサーから100,000イベント生成、ゼロドロップイベント要件
    • nonlossyblockenv(環境変数起動):DOTNET_EventPipeBufferingModeの検証、非ストリーミングファイルセッションでBlock モード拒否、ストリーミングBlock モードで50,000イベントゼロロス検証
  • 診断クライアント更新(テスト用vendored版):

    • IpcCommands.cs:CollectTracing3~6コマンドID追加
    • EventPipeSessionConfiguration.cs:バッファリングモード、V2~V6ワイヤシリアライゼーション対応
    • EventPipeSession.cs:CollectTracing コマンド選択ロジック、セッション破棄・停止動作変更
    • EventPipeProvider.cs:CollectTracing5+向けプロバイダー単位のイベントIDフィルタ対応
    • DiagnosticsClient.cs:EventPipeSessionConfiguration引数オーバーロード追加
  • IpcTraceTest拡張:バッファリングモード対応、イベント損失検証(fail-on-events-lost)、セッション開始・停止オーケストレーション更新

  • ドキュメント:README.mdにBlock モード検証実行方法を記載

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

破壊的変更(テスト用コード内):EventPipeSession.Dispose()がアクティブセッションを停止しなくなりました。既存テスト(例:src/tests/profiler/eventpipe/eventpipe.cs)が破棄時のセッション停止に依存している場合、Stop()呼び出しの明示的追加が必要です。Copilotレビューでは、ハング防止とテスト互換性のバランスに関する注記がサプレッスされています。


#132780 Reduce Unix Process.Start path resolution allocations

概要

Unix環境でのProcess.Startのパス解決処理を最適化し、メモリ割り当てを削減するPRです。FindProgramInPathをUnix実装に移動し、ValueStringBuilderを使用して実行ファイル候補を構築し、成功時のみ文字列を確保するようにしました。また、spanベースのUTF-8 interopを活用して実行ファイルチェックを行います。

変更内容

  • ProcessUtils.Unix.cs: FindProgramInPathをUnix固有実装へ移動。ValueStringBuilderを使用した実行ファイル候補の構築処理を追加。
  • ProcessUtils.cs: プラットフォーム共通のFindProgramInPathメソッドを削除。
  • Interop.Access.cs: span ベースのUTF-8 interop用のinterop定義を追加(+5行)。
  • System.Diagnostics.Process.csproj: ビルド設定の調整。

パフォーマンスへの影響

メモリ割り当て量が大幅に削減されました:

  • macOS: Runメソッドで約59%削減(3.06 KB → 1.26 KB)、Startメソッドで約54%削減(3.32 KB → 1.52 KB)
  • Linux: Runメソッドで約57%削減(2304 B → 1000 B)、Startメソッドで約51%削減(2568 B → 1264 B)

実行速度はほぼ変化なし(1.00倍付近)。割り当て削減により、GC圧力の軽減が期待されます。

関連Issue

なし

その他

レビュアーからusingステートメント使用時の潜在的なpooled-bufferリーク(CS0728警告の抑制)について指摘がありましたが、PRは承認推奨とされています。


#132759 [main] Source code updates from dotnet/dotnet

概要

dotnet/dotnetリポジトリからの定期的なコードフロー更新です。複数の依存パッケージの更新と、ビルドスクリプトおよびテストの細かな修正が含まれています。主な変更は、Microsoft.CodeAnalysis、Microsoft.DotNet関連パッケージ、NuGet.FrameworksなどのRCおよびベータ版への更新です。

変更内容

  • 依存パッケージ更新: 複数のNuGetパッケージが新しいバージョン(5.11.0-1.26425.125、11.0.0-beta.26425.125、11.0.0-rc.1.26425.125など)に更新
  • ビルド構成: eng/Version.Details.props、eng/Version.Details.xml、eng/Versions.propsの依存関係情報を更新
  • スクリプト修正: PowerShellおよびシェルスクリプト(Get-GitHubAppToken.ps1、SetupNugetSources)の軽微な改善
  • Helix関連: job/helix-job-monitor.yml、post-build.ymlのビルドパイプライン設定の更新
  • テスト修正: 複数のテストファイルにおける数値リテラル表記の正規化(DecimalTests.cs、SqlMoneyTest.cs、ToTypeTests.csなど)
  • IL Linkerテスト: DelegateAndMulticastDelegateKeepInstantiatedReqs.csの冗長な記述削除
  • ネイティブコード: src/native/minipal/conditionvariable.cに初期化関連のコード追加

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRはMaestroによる自動コードフロー更新であり、dotnet/dotnetリポジトリの複数のサブリポジトリ(arcade、aspnetcore、cecil、roslyn、sdk、windowsdesktop、winformsなど)からの変更を統合しています。
  • 関連するソースリポジトリの変更範囲の詳細はPRに記載されているコミット比較リンクで確認できます。

#132735 Improvements to native AOT method debug information

概要

Native AOTで生成されるデバッグ情報(CodeView/PDB)の改善により、デバッガがメソッドおよびパラメータの型情報をスタックトレースに表示できるようになります。主な改善点は以下の通りです:

  • メソッドの型情報をCodeView記号に含める(methodTypeIndexを非ゼロ値で設定)
  • VS デバッガのようなC#形式のメソッド名を表示(マングルされたシンボル名の代わり)
  • 暗黙的なthisパラメータを適切に命名(デバッガが署名に含めないようにするため)

修正前はパラメータint nが表示されず、修正後は正しく表示されます。

変更内容

  • CSharpTypeNameFormatter.cs:C#スタイルの型およびメソッド名を生成する新規フォーマッタを追加
  • EcmaMethodIL.Symbols.cs:暗黙的インスタンスパラメータを"___this"から"this"に変更
  • ObjectWriter.Aot.cs、CoffObjectWriter.Aot.cs、CodeViewSymbolsBuilder.cs:メソッド型IDとメソッド表示名をCodeViewS_GPROC32_IDレコードに常に出力するよう修正
  • DwarfInfo.cs:DWARF出力時のシーケンスポイント処理ロジックを更新
  • datadescriptor.inc:NativeAOT cDACコントラクトのSymbolNameバージョンをn1からn2に更新
  • ILCompiler.TypeSystem.csproj:新規フォーマッタをビルドに追加

パフォーマンスへの影響

影響なし

関連Issue

#117309

その他

互換性上の注意:cDACコントラクトSymbolNameのバージョン番号がn1からn2に変更されており、ダンプリーダーの互換性に影響を与える可能性があります。レビュアーから、対応する契約実装・仕様の更新が必要かどうかの確認が指摘されています。


#132728 Add custom error handling to LibraryImport source generation

概要

LibraryImport ソースジェネレータに、メソッドレベルの ErrorHandlerAttribute(メタデータ名で認識)を使用したカスタムネイティブエラーハンドリング機能を追加しました。エラー値の取得元として、ネイティブ戻り値、最終マネージ型の out/ref パラメータ、隠れた最終ネイティブパラメータ、隠れた戻り値をサポートします。エラー変換は論理的な戻り値と通常の出力変換の前に実行され、エラーマーシャラーが無効なネイティブ出力を読む前に例外をスローできます。SetLastError=true の場合、システムエラーはネイティブ呼び出し直後にキャプチャされ、成功後に復元されます。

[CustomMarshaller(typeof(NativeError), MarshalMode.Default,
    typeof(NativeErrorMarshaller))]
static class NativeErrorMarshaller
{
    public static NativeError ConvertToManaged(int error)
    {
        if (error < 0) throw new NativeErrorException(error);
        return new NativeError(error);
    }
}

[LibraryImport("NativeLibrary")]
[ErrorHandler(typeof(NativeErrorMarshaller), ErrorLocation.ReturnValue)]
static partial void Invoke();

変更内容

  • パーサー/モデリング: ErrorHandlingInfoParser を新規追加し、ErrorHandlerAttribute を解析。TypePositionInfo にエラー処理フラグ・インデックスを追加し、SignatureContext 経由でスレッド化
  • スタブ生成: ネイティブシステムエラーのオプショナル取得とエラーマーシャラー実行を実装。エラー変換を他の出力変換より前に実行
  • エラーロケーション: ReturnValue(ネイティブ戻り値)、LastParameter(最終パラメータ経由)、HiddenLastParameter(隠れた最終パラメータ)、HiddenReturnValue(隠れた戻り値 + 論理戻り値用隠れた最終 out パラメータ)をサポート
  • クリーンアップ順序: アンマネージド入力クリーンアップはエラー変換前に実行、エラー所有リソースのクリーンアップはエラー変換後に実行
  • テスト: 306 件合格(LibraryImportGenerator.Tests)、735 件合格(Unit Tests)。すべてのエラーロケーション、順序、クリーンアップシナリオをカバー
  • 参照アセンブリ: ErrorHandlerAttribute/ErrorLocation はフレームワーク参照アセンブリには追加されていません(メタデータ名による認識のみ)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 複数の ErrorHandlerAttribute がある場合は属性順序ではなく非サポート構成として報告
  • ref パラメータのエラーハンドラーは双方向のままで、未マネージド入力クリーンアップはエラー変換例外時にも実行
  • エラー変換成功時の通常の呼び出し元割り当てリターン/出力値のクリーンアップはスキップ(初期化されていない可能性があるため)
  • SetLastError=true

#132539 JIT/Interp: Remove MAYBENULL TypeHandle -> RuntimeType Helper uses

概要

MAYBENULL TypeHandle → RuntimeType ヘルパー関数を廃止し、null チェックをインライン化するように変更します。JIT と Interpreter の両方で、(handle == 0) ? default(RuntimeTypeHandle) : CORINFO_TYPEHANDLE_TO_RUNTIMETYPEHANDLE(handle) 相当のチェックを直接生成します。Interpreter には maybe-null 引数を持つヘルパー呼び出しを処理するための新しいオペコードが追加されました。

変更内容

  • System.Private.CoreLib: MAYBENULL ヘルパーの使用を削除(1 追加/12 削除)
  • CorInfo インターフェース: MAYBENULL 関連の定義を廃止(corinfo.h、jithelpers.h から削除)
  • JIT(importer.cpp、importercalls.cpp): TypeHandle → RuntimeTypeHandle 変換箇所でインライン null チェック生成に変更
  • Interpreter(interpreter/compiler.cpp、intops.def): 新オペコード追加、maybe-null ヘルパー呼び出し処理に対応
  • gentree.cpp: null チェック関連の処理を簡素化
  • NativeAOT: RuntimeTypeHandle 関連の実装を調整
  • JIT バージョン GUID: 更新(jiteeversionguid.h)
  • テスト: refanytype1.il にテストケース追加

パフォーマンスへの影響

ヘルパー関数呼び出しをインライン化することで、呼び出しオーバーヘッドが削減され、より効率的なコード生成が可能になります。ただし具体的なベンチマーク結果は提供されていません。

関連Issue

#132343、#132185

その他

  • 内部実装の変更です(パブリック API への影響はありません)
  • Interpreter に新しいオペコードが導入されるため、jiteeversionguid.h が更新されています

#132098 Use nearest prime sizing for collection trimming

概要

Dictionary<TKey, TValue>とHashSet<T>のTrimExcessメソッドが、成長指向のキャッシュ済みプライム数を使用する代わりに、最も近い有効なプライム数を選択するように改善されました。これにより、トリミング後の保持ストレージが最大約19%削減されます。構築、EnsureCapacity、自動成長時には既存のキャッシュ済みプライム動作を維持します。プライム選択ロジックはlibraries/Commonに統合され、重複実装が排除されました。

変更内容

  • System.Private.CoreLib/Collections/HashHelpers.cs: 新しいGetPrimeAtLeastメソッドを追加し、プライム数検索ロジックを最適化。キャンディデート探索を6k ± 1に限定し、平方根制限を再利用することで33-36%の高速化を実現
  • Dictionary.cs/HashSet.cs: TrimExcessで最も近いプライム数を使用するよう変更。コンパクト化リサイズ/コピーヘルパーを導入
  • System.Reflection.MetadataLoadContext/HashHelpers.cs: MetadataLoadContextの重複するHashHelpersを削除し、共有実装に統一
  • テストファイル: Dictionary.TrimExcessとHashSet.TrimExcessの新しいキャパシティ選択動作を検証する回帰テストを追加

パフォーマンスへの影響

プライム検索(キャッシュ外フォールバック):

  • 1,000の最小値: 67.51 ns → 43.22 ns(36%改善)
  • 5,001,234の最小値: 2.185 µs → 1.458 µs(33%改善)
  • 1,000,000,000の最小値: 30.04 µs → 19.85 µs(34%改善)

TrimExcessメモリ削減:

  • Dictionary<int, int>(5,001,234要素): 114.43 MB → 95.39 MB(19.04 MiB削減)
  • HashSet<int>(5,001,234要素): 91.54 MB → 76.31 MB(15.23 MiB削減)
  • コピースループット: 時間比率は0.98-1.06倍で混在(実質的な影響なし)

関連Issue

#132051

その他

  • 破壊的変更なし: 公開APIは変更されず、内部実装のみの改善
  • 注記: Copilotレビューで、大きなmin値(例:int.MaxValue)に対してGetPrimeAtLeastCoreが無限ループに陥る可能性が指摘されていますが、TrimExcessの実装で適切に処理されているか確認が必要

#131932 Fix nested readonly collection ctor parameters

概要

Configuration Binder ソースジェネレータが、読み取り専用コレクション型のコンストラクタパラメータを持つネストされたメンバーの初期化に失敗する問題を修正しました。修正前は参照型はnullに、値型はdefaultに暗黙的にバインドされていましたが、リフレクションバインダーとの動作の乖離がありました。

public record Inner(IReadOnlyList<string> Values);
public class Outer
{
    public Inner? Nested { get; set; }  // 修正前: null, 修正後: 正しく初期化
}

変更内容

  • CoreBindingHelpers.cs: メンバーがバインド可能かを判定するIsBindableAsMember述語を抽出・拡張。参照型でコンストラクタパラメータをバインドする型について、CanInstantiateチェックを追加することで、ネストされたメンバーの初期化ロジック(InitializeInnerなど)の呼び出しを可能に。
  • テストファイル: ネストされた参照型・値型・null許容値型、コンストラクタパラメータと設定可能プロパティのマッチングなど、複数シナリオをカバーするテストを追加。

パフォーマンスへの影響

影響なし。修正は以前スキップされていた型の初期化を追加するもので、既存のコード生成パスや検査ロジックは変更されません。ジェネレータ実行時のCanInstantiateチェックはO(1)の操作です。

関連Issue

#131399(#131358が修正したトップレベルケースのネストメンバー版の既存ギャップ)

その他

  • 参照型は??=で既存インスタンスを保持、値型は=で直接割り当て(構造体のコピーセマンティクスに対応)
  • コンストラクタパラメータとセットのみプロパティの両方に対応する述語の共有により、二重初期化を防止
  • リフレクションバインダーとソースジェネレータのバインディング動作の一致を確保

#131732 Skip making empty loops for collections of non-bindable elements

概要

ConfigurationBinder ソースジェネレータが、要素型を構築できない非辞書コレクション(例:抽象クラスの要素型)に対して空の BindCore メソッドを生成しないように修正します。インターセプタの動作(引数検証、非サポートオプションの例外スロー)は保持されます。

修正前の問題コード例:

// 非バインド可能な要素型に対して空のループが生成される
public static void BindCore(IConfiguration configuration, ref EndPointCollection instance, bool defaultValueIfNotFound, BinderOptions? binderOptions)
{
    foreach (IConfigurationSection section in configuration.GetChildren())
    {
    }
}

変更内容

  • TypeIndex.cs: コレクションの HasBindableMembers を修正し、リスト/配列/セットは「要素型が構築可能か」を判定するよう変更。辞書は既存の「バインド可能か」の判定を維持
  • BindingHelperInfo.cs: 非辞書コレクションでバインディングロジックがない場合、要素型の登録を回避。ただし CanInstantiate でインターセプタは維持
  • CoreBindingHelpers.cs: 「バインドするものがない」型に対して適切にハンドルするよう、不適切なアサーションを削除
  • ConfigurationBinder.cs: HasBindableMembers がfalseでも、ArgumentNullException.ThrowIfNull と GetBinderOptions 呼び出しを常に生成(リフレクションバインダとの互換性維持)
  • Helpers.cs: null チェック生成時に空行の制御を追加
  • テスト追加: 非構築可能な要素型コレクションと Configure<T> のnoキシナリオをカバーする回帰テスト
  • ベースラインファイル: 診断レポート数の変更を反映し更新

パフォーマンスへの影響

影響なし。生成コードの最適化(不要な空ループの排除)により、わずかにコード量が削減されます。

関連Issue

#92151

その他

  • 互換性: ジェネレータレベルの変更で公開APIへの影響なし。生成されるインターセプタは引数検証を常に行うため、リフレクションバインダとの互換性を保持
  • 既知のアーティファクト: get-only コレクションメンバーに対しては、空の if ブロックが残されます。これは既存の同様なケース(バインド対象がない型)と同じであり、直行する問題として分離されています
  • 注記: BinderOptions.ErrorOnUnknownConfiguration = true の場合、リフレクションバインダと生成バインダの動作に違いがあります。この変更前後で違いは変わりません

#131161 [cDAC] WebAssembly: captured R2R stack-walk fixture validation

  • 作成者: @lewing
  • 作成日時: 2026年07月21日 17:04:49(UTC)
  • マージ日時: 2026年08月31日 16:27:19(UTC)
  • ラベル: area-VM-coreclr

概要

WebAssemblyのReadyToRun (R2R)スタックウォーク機能に対するcDAC(Compact Diagnostic Access Component)テストを強化します。空のFunctionTableIndexRangeListケースの検証と、実際のディスパッチング複合R2Rイメージから取得した完全なランタイム関数テーブルを使用した統合テストを追加します。また、XML コメントで WASM フレームレイアウトのネイティブソース参照を修正します。

変更内容

  • WasmR2RInfo.cs / WasmUnwinder.cs: XML コメントの修正と、空のランタイム関数テーブル処理の改善(合計 +1/-1、+3/-2)
  • WasmR2RInfoTests.cs: テストカバレッジを大幅拡張(+125行)
    • EmptyRangeList_ResolvesToNoSectionテスト:空のFunctionTableIndexRangeListが仮想IPベース取得とアンワインドデータ取得の両方で「クリーンなミス」を返すことを検証
    • 実データフィクスチャテスト:MinFunctionTableIndex = 6259、NumRuntimeFunctions = 45283の実際のディスパッチング複合イメージから取得したデータを使用
    • テーブル範囲境界検証とエンドツーエンドの仮想IP復元テストを追加
    • フルサイズのテーブル(45,283エントリ)を割り当てて、テーブルサイズ・ストライド・境界バグの検出可能性を向上

パフォーマンスへの影響

影響なし(テストスイート追加のため、本体コードへの実行時パフォーマンス影響なし)

関連Issue

なし

その他

  • テスト実績:cDAC単体スイート 3,029 合格 / 16 スキップ / 0 失敗、WasmR2RInfoTests 6 合格、WASM R2R/アンワインダー統合テスト 18 合格、Contract 利用テスト 4 合格、CdacUsageGraph テスト 85 合格
  • フィクスチャデータの出所:WASI corerun-composite.wasm (MD5: a978074b91cd722574b308f52c9ca994)から検証済みの実データを抽出
  • System.Exception::.ctor()メソッド(トークン0x060004AB)など、トークン単位での検証を含む
  • GitHub Copilot の支援により作成されたPull Request

目次