Pull Request on 2026年10月20日

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

注意点

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

目次

  1. #136172 [clr-interp] Preserve byref-like locals when an await does not suspend
  2. #136170 [release/8.0] Skip file-backed named mutex tests on Mono
  3. #136168 Reuse handle-based unwind lookup for WebAssembly
  4. #136159 ILVerify: fix crashes on non-array element operands and on ldelem.ref of null
  5. #136149 JIT: Preserve volatile static reads when folding readonly fields
  6. #136147 Cleanup unused cmake configs
  7. #136139 Fix AcceptWithDefaultValidation_CertificateContextTrust_HonorsChainPolicy test failures
  8. #136135 ILVerification.Tests: reject unknown error names
  9. #136131 coreclr: default EnableWriteXorExecute to 0 on OpenHarmony
  10. #136129 Add native AOT to DefaultCoreClrSubsets on WASI
  11. #136128 Home DIM instantiating thunks on System.Object
  12. #136125 Reject NativeAOT closed static delegates over non-reference first parameters
  13. #136124 [release/8.0] Update branding to 8.0.34
  14. #136123 [release/9.0] Update branding to 9.0.23
  15. #136120 Correct x86 instruction metadata
  16. #136119 Guard EncryptedXml_DecryptDocument_MaxCount_Default with RemoteExecutor.IsSupported
  17. #136116 Require threads for ControlledExecutionTests.CancelInTryAndExitCatchNormally
  18. #136114 [CI] Report compiler cache statistics after runtime test builds
  19. #136112 Add ilverify --list-errors to list the names --ignore-error matches
  20. #136109 [Bugfix] Clear removed elements in ImmutableArray<T>.Builder
  21. #136089 [cDAC] Fix incorrect filtering of stack-interior references
  22. #136072 Restart HttpListener authentication when protection policy changes
  23. #136063 Make whole-list ImmutableList<T>.Reverse() O(n)
  24. #136050 [wasm][R2R] Fix calls through MethodImpl-redirected slots on portable entrypoints
  25. #136040 JIT: inline box Nullable<T> in ReadyToRun
  26. #136033 ilverify: respect IgnoresAccessChecksToAttribute
  27. #136021 JIT: keep lea esp, [ebp] in x86 epilogs
  28. #136006 [wasi] Set RUNTIME_IDENTIFIER and ENTRY_ASSEMBLY_NAME in wasihost
  29. #135991 [wasm] Fix single-register struct call result stores (narrow stores, GC write barrier)
  30. #135983 [browser] Make SystemJS_GetLocaleInfo argument order consistent
  31. #135968 [release/11.0] cDAC: skip empty assembly-list slots in Loader_1.GetModuleHandles
  32. #135956 Simplify frozen object heap allocation
  33. #135952 Resolve WASI SDK for NativeAOT runtime test builds
  34. #135893 JIT: Gate single-edge root profile trust on hotness or speed preference
  35. #135863 corehost: singlefilehost fixes for OpenHarmony
  36. #135853 JIT: spill local refs for COMMA-wrapped local stores in impAppendStmt
  37. #135837 JIT: ignore finally-entry backedges when fixing continuation weights
  38. #135823 JIT: preserve null checks when folding ThrowIfNull in Tier0
  39. #135731 Merging internal commits for release/8.0
  40. #135727 Merging internal commits for release/8.0
  41. #135653 Load CoreCLR browser-WASM PDBs into memory instead of the VFS
  42. #135494 [cDAC][wasm] Keep caller SP for non-R2R callers and restore SoftwareExceptionFrame FP
  43. #135146 [wasm] [JIT] Contain Array Data Offsets
  44. #135067 Enable ILLink caching and post-build purging in CI
  45. #135066 Support ILLink caching in runtime library builds
  46. #134910 [JIT] Rationalize: Re-run pre-order processing on identity shuffle rewrite in PreOrderVisit
  47. #134819 Update x64 Helix test VMs to Azure Linux 4
  48. #133533 Convert .data tls IL tests to C++/CLI
  49. #131428 Ensure that x64 disassembly names operands at the size actually encoded
  50. #129510 [release/10.0] Fix MemoryCache negative _cacheSize drift that permanently latches a size-limited cache

#136172 [clr-interp] Preserve byref-like locals when an await does not suspend

概要

インタープリターの継続ハンドラー（通常/ジェネリックの両継続opcodeが共有）で、await が同期的に完了して中断しない場合に、初期化済みのローカル（byref-like ローカルを含む）が誤ってゼロクリアされる問題の修正です。「継続なし」の高速パスを、ローカルのゼロクリアより前に移動しました。実際に中断する場合は、従来どおり継続処理の前にゼロクリアします。Resolves dotnet/runtime#136171。

変更内容

  • src/coreclr/vm/interpexec.cpp: 共有ハンドラー内の処理順を変更し、継続がない場合の高速パスをローカルのゼロクリアより前に実行するようにしました。実中断時のゼロクリアと継続キャプチャは変更していません。
  • src/tests/JIT/Regression_ro_2/Runtime_136000.cs: 既存の Runtime_136000.TestEntryPoint を、ジェネリック/非ジェネリックな包含型と ref struct/byref ローカルの組み合わせによる4ケースの条件付き Theory に拡張しました。各ケースで、Task.CompletedTask に対する保持、保留中タスクの未完了結果、実中断後のデフォルト化を検証します。通常の byref の初期化には NoInlining の ref identity ヘルパーを使い、ローカルのアドレス再計算ではなく継続ローカルのクリア処理を検証できるようにしています。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載はありません）。

関連Issue

#136171

その他

  • このテストは #136085 で追加されたもので、同PRはネイティブJITの継続キャプチャに関する別の問題を修正しています。インタープリターの「チェック前クリア」の挙動はそのテストより前から存在していました。
  • 作成者によると、ローカルのアドレスを直接使うプロトタイプでは、中断後にネイティブJITでアドレスが再マテリアライズされる別の問題が見つかっています。本PRはJITコードを変更せず、byrefケースも無効化していません。
  • 検証（作成者報告）:
    • 修正前のWasmランタイムでは、元の回帰テストが想定どおり失敗しました。
    • 修正後のWasmランタイムでは、拡張した回帰テスト16/16が成功しました。
    • 関連する async テスト36/36が成功しました。
    • 同一ソースのネイティブARM64 JITでは4/4が成功しました。
    • 検証はNode.js上のbrowser/Wasmターゲットで行っています。実際のCIバイナリ、R2Rコンパイル済み呼び出し元、Mono、他のネイティブアーキテクチャ、async スイート全体は検証対象外です。
  • スコープ: 変更は共有ハンドラーの処理順のみで、ネイティブJITのソース、Reflection.Emit、R2R、パイプラインは変更していません。

#136170 [release/8.0] Skip file-backed named mutex tests on Mono

概要

release/8.0ブランチにおいて、Mono上でファイルバックの名前付きMutexに関するテスト2件をスキップするようにする変更です。Monoの名前付きMutex実装は共有メモリのバッキングファイルを使用しないため、これらのテストはMonoには適用されません。テストコードのみの変更です。

変更内容

  • src/libraries/System.Threading/tests/MutexTests.cs (+2/-0)
    • Mono上でファイルバックの名前付きMutexテスト2件をスキップする処理を追加（追加2行）

パフォーマンスへの影響

影響なし

関連Issue

#136060

その他

  • ランタイムやライブラリ本体、公開APIへの変更はなく、互換性への影響もありません。
  • 提供された情報には、スキップされるテスト名や具体的なスキップ方法の詳細は含まれていません。

#136168 Reuse handle-based unwind lookup for WebAssembly

  • 作成者: @rcj1
  • 作成日時: 2026年10月20日 18:06:44(UTC)
  • マージ日時: 2026年10月20日 21:39:14(UTC)
  • ラベル: area-Diagnostics-cdac

概要

WebAssembly (WASM) の R2R アンウィンドデータ検索を、専用の「制御PCのみ」の検索経路から、既存の ExecutionManager のハンドルベース API を再利用する形に統一する変更です。他アーキテクチャと同じ検索パターンに揃え、IExecutionManager.TryGetUnwindInfo とその実装を削除します。

変更内容

  • WasmR2RInfo.TryGetUnwindData が、仮想 IP を GetCodeBlockHandle で解決し、GetUnwindInfo と GetUnwindInfoBaseAddress からランタイム関数エントリとイメージベースを取得するように変更（コードブロックやアンウィンド情報が取得できない場合の失敗時の挙動は維持）
  • IExecutionManager.TryGetUnwindInfo を削除（IExecutionManager.cs、ExecutionManagerCore.cs、ExecutionManager_1.cs）
  • ルートメソッドとファンクレットのアンウィンドデータ解決を、実際の ExecutionManager 経由で検証するテストを追加（WasmR2RInfoTests.cs）
  • スタックウォークのテストダブルおよび既存テストを更新（StackWalkTests.cs、WasmUnwinderTests.cs、ExecutionManagerTests.cs）
  • データコントラクトのドキュメントを更新（ExecutionManager.md、StackWalk.md）

パフォーマンスへの影響

影響なし（パフォーマンスに関する記載・ベンチマーク結果は提供情報にありません）

関連Issue

なし

その他

  • 検証は、タグ付きフレーム ABI に一致する CI ランタイムと crossgen2 に対し nesm で実施。例外ディスパッチ、ネイティブ仮想アンウィンド、第1パスのフィルター、第2パスのディスパッチ・呼び出し、finally ファンクレットの6地点で取得したスナップショットを使用
  • ブランチとベースラインで、公開 IStackWalk の結果が完全に一致（リーダーあたり135エントリ、うちマネージドフレーム98）
  • 本番の WasmContext.Unwind 94ステップ（呼び出し元の SP/IP/FP を含む）と、33フレームインスタンスの MethodDesc／アンウィンドデータのコールド解決も同一結果
  • 検証対象は CI ランタイムに対する cDAC のアンウィンドであり、このブランチから再ビルドしたネイティブランタイムではない点に注意
  • 作成者の説明によれば、PR 説明は GitHub Copilot により生成

#136159 ILVerify: fix crashes on non-array element operands and on ldelem.ref of null

概要

ILVerifyが、配列ではないオペランド（例: string）を ldelem.* / stelem.* / ldelema に渡された場合に InvalidCastException でクラッシュする問題を修正します。修正後は ExpectedArray を報告し、そのメソッドの検証を中断します。また、null配列に対する有効な ldelem.ref で NullReferenceException が発生する問題も修正します。

クラッシュを再現するILの例:

.method public static void M() cil managed
{
    ldstr "a"
    ldc.i4.0
    ldelem.i4
    pop
    ret
}

変更内容

  • src/coreclr/tools/ILVerification/ILImporter.Verify.cs (+7/-3)
    • CheckIsArray が失敗した場合に AbortBasicBlockVerification() を呼ぶようにしました。これは CheckIsIndex、CheckIsByRef、CheckIsNumeric、CheckIsInteger と同じ扱いです。ImportLoadElement / ImportStoreElement / ImportAddressOfElement の ((ArrayType)array.Type).ElementType へのキャストに到達しなくなります。
    • ImportLoadElement で ldelem.ref の配列が null（array.Type が null）の場合、ldnull と同様に null 参照をスタックにpushするようにしました。ECMA-335 (III.4.7, III.4.8) では、null配列参照は実行時に NullReferenceException となる有効なILです。
  • src/coreclr/tools/ILVerification.Tests/ILTests/ArrayTests.il (+87/-0)
    • テストメソッドを9件追加しました。
      • stringを配列オペランドとする _Invalid_ExpectedArray が7件（ldelem.i4、ldelem.ref、ldelem <token>、stelem.i4、stelem.ref、stelem <token>、ldelema）
      • int32 を配列オペランドとする ldelem.ref の _Invalid_ExpectedArray が1件
      • null配列に対する ldelem.ref の LoadElement.RefFromNull_Valid が1件

挙動の変化として、ldlen の非配列オペランドや多次元配列への要素アクセスも CheckIsArray を通ります。これらは以前もクラッシュせず ExpectedArray を報告していましたが、今後はそこで検証を中断します。

パフォーマンスへの影響

影響なし

関連Issue

  • #136159（本PR）
  • dotnet/roslyn#58652（RoslynのVBテスト TestGetObjectValueCalls で同じILVerifyのクラッシュが報告されている。ldnull; ldc.i4.1; ldelem.ref を含むメソッドが該当）

その他

  • 検証結果:
    • 修正適用時は ILVerification.Tests が Release / Debug とも 528/528 で成功しました。main は 519/519 です。
    • 修正を両方戻すと、追加した9件だけが失敗します。7件は InvalidCastException、int32 の1件とnullの1件は NullReferenceException です。
    • 10.0.12 共有フレームワークの172アセンブリに対してILVerify CLIを main と本PRで実行し、出力が同一であることを確認しています（ExpectedArray やクラッシュは両者で発生せず、想定通り）。
  • 作成者の記載によると、PRはAI（Anthropic Claude、OpenAI Codex）の支援を受けて作成され、作成者がレビュー済みです。

#136149 JIT: Preserve volatile static reads when folding readonly fields

  • 作成者: @EgorBo
  • 作成日時: 2026年10月20日 12:54:15(UTC)
  • マージ日時: 2026年10月20日 15:55:03(UTC)
  • ラベル: area-CodeGen-coreclr

概要

NativeAOTが「書き込まれない static フィールドは readonly である」と推論した場合に、そのフィールドの volatile 読み取りまで定数畳み込みされ、acquire セマンティクスが失われる問題を修正します。これにより、後続のロードがスピンループの外へホイスト（巻き上げ）される回帰が発生していました（#135724 のコメントで報告）。修正として、volatile アクセスの場合は readonly フィールドの畳み込みをスキップします。

変更内容

  • src/coreclr/jit/importer.cpp（+3/-2）
    • JIT のインポーターで readonly フィールドを定数畳み込みする処理に対し、volatile 読み取りを除外する条件を追加

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載はありません）。volatile 読み取りに限り畳み込みが行われなくなるため、その範囲では最適化が抑制されますが、正しいメモリセマンティクスを維持するための変更です。

関連Issue

  • #135724（回帰が報告されたPR）

その他

  • 影響範囲は JIT コンパイラ内部の実装（公開APIの変更や互換性への影響の記載はなし）
  • 主に NativeAOT で、書き込みのない static フィールドが readonly と推論されるケースに関係します

#136147 Cleanup unused cmake configs

概要

ネイティブライブラリ、CoreCLR PAL、GCのビルド構成から、使用されていないCMakeの機能検出（プローブ）と設定値を削除するクリーンアップです。生成ヘッダーの対応する定義や、クロスコンパイル用のキャッシュエントリも併せて整理されています。ランタイムの公開API・動作に関わる変更ではなく、ビルドシステム内部の整理です。

変更内容

  • src/native/libs/configure.cmake: 未使用のライブラリプローブと関連するインクルード設定を削除 (-20)
  • src/coreclr/pal/src/configure.cmake: 未使用のPALプローブと定数を削除 (-153)
  • src/coreclr/pal/src/config.h.in: 上記に対応するPALの構成定義を削除 (-14)
  • src/coreclr/gc/unix/configure.cmake: 未使用のスレッドIDプローブを削除 (-12)
  • src/coreclr/gc/unix/config.gc.h.in: 対応するGC側の定義を削除 (-1)
  • src/coreclr/CMakeLists.txt: 不要になったWASIのプローブ結果を削除 (-2)
  • eng/native/tryrun.cmake: 不要なクロスコンパイル用キャッシュエントリを削除 (-16)
  • eng/native/tryrun.browser.cmake: ブラウザ向けの未使用キャッシュエントリを削除 (-25)
  • eng/native/tryrun_ios_tvos.cmake: Apple モバイル向けの不要なプローブ結果を削除 (-7)

すべて削除のみの変更です（追加行なし）。

パフォーマンスへの影響

影響なし（提供された情報にベンチマーク結果やランタイムの性能に関する記載はありません。なお、CMake構成時のプローブ数が減るため、構成処理がわずかに軽くなる可能性はありますが、情報としては確認できません）。

関連Issue

なし

その他

  • Copilotのレビュー要約では、削除内容はプローブ・ヘッダー・クロスコンパイルキャッシュ間で一貫しており、未解決の指摘事項はないとされています（静的レビューのみで、ビルドとテストは未実行）。
  • 作成者による概要の記載はありません。

#136139 Fix AcceptWithDefaultValidation_CertificateContextTrust_HonorsChainPolicy test failures

  • 作成者: @rzikm
  • 作成日時: 2026年10月20日 09:05:36(UTC)
  • マージ日時: 2026年10月20日 20:36:23(UTC)
  • ラベル: area-System.Net.Security

概要

TlsSessionTests.cs を修正し、AcceptWithDefaultValidation_CertificateContextTrust_HonorsChainPolicy テストの失敗（#136096）に対処するPull Requestです。変更は1ファイルの1行削除のみです。

変更内容

  • src/libraries/System.Net.Security/tests/FunctionalTests/TlsSessionTests.cs: 1行を削除（+0/-1）
    • 削除された行の具体的な内容は提供情報に含まれていないため不明です。

パフォーマンスへの影響

影響なし（テストコードのみの変更）

関連Issue

#136096

その他

  • 変更対象はテストコードのみで、公開APIやランタイム/ライブラリの実装、互換性への影響はありません。
  • Pull Requestの説明にはIssueへのリンクのみが記載されており、失敗の原因や修正方針の詳細は提供情報からは確認できません。

#136135 ILVerification.Tests: reject unknown error names

概要

ILVerification.Tests のテストローダー（TestDataLoader）が、_Invalid_ メソッド名に含まれる期待エラー名を Enum.TryParse で解析し、VerifierError に該当しない名前を黙って無視していた問題を修正します。無視されると、テストが名前に書かれたより少ないエラーしか期待せず、スペルミスなどでテストが弱体化してしまうためです。本PRはテストのみの変更で、不明なエラー名があればテスト名と不明な名前を含むメッセージで例外を投げるようにします。

出力例:

System.ArgumentException : Test 'StoreLocUninit' expects 'StackUninit', which is not a VerifierError.

変更内容

  • TestDataLoader.cs: 期待エラー名が VerifierError として解析できない場合に ArgumentException をスローするよう変更（+16/-5）。_InvalidType_ 側も同じチェックを使い、従来の Enum.Parse 由来の例外ではなくテスト名入りのメッセージになります。
  • ExceptionRegionTests.il: Leave.ToOtherFault_Invalid_LeaveOutOfFault.LeaveIntoFault.LeaveIntoHandler を Leave.ToOtherFault_Invalid_LeaveOutOfFault.LeaveIntoHandler にリネーム。LeaveIntoFault というコードは存在せず、従来も実際には LeaveOutOfFault と LeaveIntoHandler のみを検証していたため、検証内容は変わりません。
  • ThisStateTests.il: special.StoreLocUninit..ctor_Invalid_StackUninit を special.StoreLocUninit..ctor_Valid にリネーム。StackUninit は UninitStack の誤記と思われますが、コンストラクタは int32 ローカルに 0 を格納するだけで this を格納しないため検証可能で、ILVerify はエラーを報告しません。従来もエラーなしを期待していたため、検証内容は変わりません。

パフォーマンスへの影響

影響なし（テストコードのみの変更）。

関連Issue

なし

その他

  • 不明なエラー名があると TestMethodsWithInvalidIL が1件の失敗結果として報告され、その間は他の無効IL（invalid-IL）ケースが実行されません。テストケースに新しいフィールドを追加せずに済むため、この方式が採用されています。
  • テスト結果: ILVerification.Tests は Release/Debug ともに 519 件が成功し、main と同数です。元の名前を戻すと新しいメッセージで失敗し、ローダーの変更を戻すと元の名前は再び通ることが確認されています。メソッド名・型名に仕込んだスペルミスもそれぞれ新メッセージで失敗します。
  • 作成者によると、本PRは AI（Anthropic Claude、OpenAI Codex）の支援のもとで作成され、作成者がレビュー済みとのことです。

#136131 coreclr: default EnableWriteXorExecute to 0 on OpenHarmony

概要

OpenHarmony 上の CoreCLR で EnableWriteXorExecute（W^X）のデフォルト値を 0 にする変更です。

  • W^X アロケーターは、memfd をバックにした同一ページを「読み書き用ビュー」と「読み取り＋実行用ビュー」の二重マッピングで管理します。
  • OpenHarmony のサンドボックスは、ファイルバックのマッピングへの PROT_EXEC を拒否します（匿名の実行可能メモリは許可）。そのため実行用ビューを作成できず、JIT コンパイルされたコードを実行できません。
  • 既存の RISC-V 向けの条件（デフォルト 0 で RWX アロケーターを選択）に TARGET_OPENHARMONY を加え、OpenHarmony ビルドで JIT が追加設定なしに動作するようにします。
  • ノブ自体は変更されておらず、DOTNET_EnableWriteXorExecute=1 を指定すれば引き続き W^X を要求できます。

変更内容

  • src/coreclr/inc/clrconfigvalues.h
    • EXTERNAL_EnableWriteXorExecute を囲むガードを #ifdef TARGET_RISCV64 から #if defined(TARGET_RISCV64) || defined(TARGET_OPENHARMONY) に変更し、両ターゲットでデフォルトを 0 にしました。
    • サンドボックス上の理由を示すコメント 2 行と、末尾の #endif コメントを追加しました。
    • 差分は 4 行追加・2 行削除です。

影響範囲

  • ランタイムの内部設定（CLR config のデフォルト値）の変更で、公開 API の変更ではありません。
  • TARGET_OPENHARMONY は #132953 のプラットフォームビルドサポートで定義されます。RISC-V を含む他のターゲットは従来どおりの分岐を通り、デフォルト値 1 を維持します。
  • マネージド API、ビルド、テストの変更はありません。互換性への影響は OpenHarmony ターゲットのデフォルト動作のみです。

パフォーマンスへの影響

ベンチマーク結果の記載はありません。WX を無効化するデフォルト（RWX アロケーター）への切り替えであり、OpenHarmony 以外のターゲットには影響しません。PR の主眼は性能ではなく、JIT コードを実行可能にすることです。 セキュリティ面では、OpenHarmony ではデフォルトで WX が無効になります。ただし、ファイルバックの実行可能マッピングを許可するサンドボックス構成向けに、DOTNET_EnableWriteXorExecute=1 でオプトインできます。

関連Issue

なし（PR 本文には、依存する PR として #132953 の言及があります）

その他

作成者による検証結果は次のとおりです。

  • OpenHarmony arm64 実機で、DOTNET_EnableWriteXorExecute 未設定かつ DOTNET_ReadyToRun=0 のフレームワーク依存コンソールアプリが最後まで実行され、実行可能アロケーターから EACCES エラーは報告されませんでした。
  • 同一ビルドで DOTNET_EnableWriteXorExecute=1 を指定すると、二重マッピングされたファイルを実行可能にする際に失敗します（このデフォルト変更が回避する事象）。
  • 実機の直接プローブでは、memfd マッピングへの PROT_EXEC 付与（mprotect）は EACCES を返す一方、匿名マッピングは RW から RX に切り替えて実行できました。

なお、PR 本文には AI 支援（エージェントツール）を用いて作成された旨の記載があります。

#136129 Add native AOT to DefaultCoreClrSubsets on WASI

概要

WASI向けビルドの DefaultCoreClrSubsets に Native AOT を追加するPRです。あわせて、サブセット一覧の並び順を整理し、ブロック冒頭の無条件版とWASI固有版を比較しやすくしています。この変更後、両者の差異は「WASIでは libs.native をCoreCLRの一部として扱う」点だけになります。

変更内容

  • eng/Subsets.props (+1/-1): WASI向け DefaultCoreClrSubsets に Native AOT を追加し、リストの並び順を整理
  • src/libraries/System.Private.CoreLib/src/System/Threading/Wasi/WasiEventPipeJobs.cs (+2/-0): 2行追加（提供情報からは具体的な内容は不明）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 作成者は MichalStrehovsky 氏です。
  • WASIで libs.native をCoreCLRの一部として扱っている理由は、作成者自身も「for some reason」としており、本PRでは変更されていません。
  • WasiEventPipeJobs.cs の変更内容は提供情報に含まれていないため、詳細は元のPRの差分を確認してください。

#136128 Home DIM instantiating thunks on System.Object

概要

NativeAOTにおけるデフォルトインターフェイスメソッド（DIM）のinstantiating thunkの配置先を、ジェネリックなインターフェイス自身ではなく、非ジェネリックな System.Object に変更する修正です。thunkがジェネリック型上にあると「instantiating argumentが必要かどうか」の判定で問題が生じ（実際には不要）、それを打ち消すための特殊処理が多数必要になるため、これを回避する局所的な修正として行われています。Issue #136073 を修正します。

作成者によると、この方法は複数オブジェクトファイル（multi-obj）モードでは機能せず、これらのthunkがすべてCoreLib.objにコンパイルされるように見える制限がありますが、他の事情を考慮すれば許容できるとされています。

変更内容

  • src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.InterfaceThunks.cs（+3/-6）: instantiating thunkのホーム（所有型）を System.Object にする変更。明示的なthunk所有者の保持やコンストラクタ引数が削除されています。
  • src/tests/Loader/classloader/DefaultInterfaceMethods/regressions/github136073.cs（+38/-0）: 回帰テストの追加。object と string を用いた共有ジェネリックのデフォルト実装を対象に、レシーバーのキャストとジェネリック型の同一性を検証します。
  • src/tests/Loader/classloader/DefaultInterfaceMethods/regressions/github136073.csproj（+5/-0）: 回帰テストのソースを含めるプロジェクトファイルの追加。

パフォーマンスへの影響

影響なし（記載された情報の範囲では、パフォーマンスに関する言及やベンチマーク結果はありません）。

関連Issue

#136073

その他

  • 複数オブジェクトファイル（multi-obj）コンパイルモードでは、thunkがすべてCoreLib.objにコンパイルされる想定となる制限があり、メンテナによる許容判断が必要です。
  • Copilotのレビューでは、NativeAOTでの実行が未検証である点が指摘されています。

#136125 Reject NativeAOT closed static delegates over non-reference first parameters

  • 作成者: @Copilot
  • 作成日時: 2026年10月20日 03:38:08(UTC)
  • マージ日時: 2026年10月20日 08:33:16(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

NativeAOT では、第1引数が参照型以外（値型など）の closed static delegate が受け入れられ、メソッドが値を期待する箇所にオブジェクト参照が渡されていました。CoreCLR ではこのバインドは拒否されます。本PRは NativeAOT の動作を CoreCLR に揃え、該当するバインドを拒否します。

  • 第1引数が値型・byref・ポインター・関数ポインターの場合は、null ターゲットも含めて拒否されます。
  • 例外をスローするオーバーロードは ArgumentException を報告します。
  • throwOnBindFailure: false の場合は null を返します。

変更内容

  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/RuntimeMethodInfo.cs (+5/-1)
    • 非参照型の第1引数を拒否するガードを追加。
  • src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DelegateTests.cs (+76/-0)
    • 影響を受ける各オーバーロード、ジェネリックのインスタンス化、非サポートのシグネチャに対するテストケースを追加。
    • 有効な参照型・インターフェース・配列のバインドが維持されることを確認するテストを追加。
    • Mono は一部のバインドを現状許容するため、拒否のアサーションは CoreCLR と NativeAOT に限定。

パフォーマンスへの影響

影響なし

関連Issue

#136101

その他

  • NativeAOT と CoreCLR の動作差異を解消する変更で、これまで NativeAOT で受け入れられていた不正なバインドが拒否されるようになります。
  • Copilot のレビュー概要によると、ビルドとテストはレビュー時に実行されておらず、CoreCLR と NativeAOT でのテスト結果は人手での確認が必要とされています。

#136124 [release/8.0] Update branding to 8.0.34

概要

release/8.0 ブランチのバージョンブランディングを更新するPRです（リリースボットによる自動作成）。パッチバージョンを 33 から 34 に変更し、8.0.34 向けのブランディングにします。

変更内容

  • eng/Versions.props（+2 / -2）
    • PatchVersion: 33 → 34

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • バージョン情報のみの変更で、コード・公開API・ランタイム/ライブラリの実装には変更ありません。
  • 互換性への影響（破壊的変更・非推奨化など）やセキュリティ修正に関する記載は、提供された情報にはありません。

#136123 [release/9.0] Update branding to 9.0.23

概要

release/9.0 ブランチのバージョンブランディングを、パッチバージョン 22 から 23 に更新するリリース管理用のPRです（9.0.23 向け）。コードやAPIの変更は含まれません。

変更内容

  • eng/Versions.props: PatchVersion を 22 → 23 に変更（+2 / -2）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • dotnet-release-bot[bot] により自動作成されたPRです。
  • 提供された情報の範囲では、互換性・セキュリティ・動作に関する変更内容は確認できません。

#136120 Correct x86 instruction metadata

概要

JITが使用するx86命令メタデータを修正するPRです。対象は、メモリサイズ、EVEX圧縮ディスプレースメント（compressed displacement）、マスキング、オペランドマッピングです。

特に VPMULDQ / VPMULUDQ は64ビットのブロードキャストメモリオペランドを使うため、JITは圧縮ディスプレースメントを8バイト単位でスケールする必要があります。この修正に合わせて、隣接フィールドのケースを検証する AVX-512 向けの符号付き・符号なし回帰テストを追加しています。あわせて関連する命令メタデータを修正し、EVEXのサイズ計算とLoweringのために quarter-width tuple（1/4幅タプル）の扱いを追加しています。

変更内容

  • src/coreclr/jit/emit.h: +12行（変更の詳細は提供情報に含まれません）
  • src/coreclr/jit/emitxarch.cpp: +17/-1行。EVEXサイズ計算に関する変更とみられます
  • src/coreclr/jit/instr.cpp / instr.h: +10行 / +2/-1行。quarter-width tuple関連の追加とみられます
  • src/coreclr/jit/instrsxarch.h: 91行を更新（x86命令メタデータの修正）
  • src/coreclr/jit/lowerxarch.cpp: +3行。quarter-width tupleの扱いに関するLowering側の変更
  • src/tests/JIT/Regression_2/Runtime_135844/: VPMULDQ / VPMULUDQ の隣接フィールドケースを検証する回帰テスト（.cs と .csproj）を新規追加

パフォーマンスへの影響

ベンチマーク結果などの記載はなく、パフォーマンスへの影響に関する情報は提供されていません。変更の主眼は、命令エンコード時のディスプレースメントスケール等の正確性の修正です。

関連Issue

#135844（このPRで解決）

その他

  • 対象はJIT（x86/x64）の内部実装であり、公開APIの変更ではありません。
  • 本PRの説明はGitHub Copilotにより生成された旨が記載されています。

#136119 Guard EncryptedXml_DecryptDocument_MaxCount_Default with RemoteExecutor.IsSupported

  • 作成者: @lewing
  • 作成日時: 2026年10月20日 01:17:33(UTC)
  • マージ日時: 2026年10月20日 03:46:41(UTC)
  • ラベル: area-System.Security

概要

EncryptedXml_DecryptDocument_MaxCount_Default（#135741で追加）は、通常の [Fact] から RemoteExecutor.Invoke を呼び出していたため、RemoteExecutorがサポートされない環境（例：runtime-coreclr crossgen2 のouterloop R2Rライブラリ実行）で PlatformNotSupportedException が発生していました。本PRでは属性を [ConditionalFact(typeof(RemoteExecutor), nameof(RemoteExecutor.IsSupported))] に変更し、RemoteExecutorが非対応の環境ではテストがスキップされるようにします。同系統の _AppContext テストと同じ方式に揃えた変更です。

// 変更後の属性
[ConditionalFact(typeof(RemoteExecutor), nameof(RemoteExecutor.IsSupported))]

変更内容

  • src/libraries/System.Security.Cryptography.Xml/tests/EncryptedXmlTests.cs（+1/-1）
    • EncryptedXml_DecryptDocument_MaxCount_Default テストの属性を [Fact] から [ConditionalFact(typeof(RemoteExecutor), nameof(RemoteExecutor.IsSupported))] に変更

パフォーマンスへの影響

影響なし（テストコードのみの変更）

関連Issue

  • #135741：対象テストが追加されたPR（Issueではなく関連PRとして記載）

その他

  • 変更はテストのみで、公開API・ランタイム/ライブラリの実装・互換性への影響はありません。
  • 失敗が確認されたビルド：build 1639697
  • 作成者によると、このPRはGitHub Copilotの支援を受けて生成されたものです。

#136116 Require threads for ControlledExecutionTests.CancelInTryAndExitCatchNormally

概要

ControlledExecutionTests.CancelInTryAndExitCatchNormally に IsMultithreadingSupported の条件を付け、スレッドが使えない環境（シングルスレッドのbrowser-wasm）ではテストをスキップするようにする1行の修正です。#135939 のマージ以降、browser-wasm CIの System.Runtime.Tests がタイムアウトしており、その原因と推測される問題への対応です。PR自体のブラウザCI実行で、タイムアウトが解消するかどうかが確認されます。

変更内容

  • src/libraries/System.Runtime/tests/System.Runtime.Tests/System/Runtime/ControlledExecutionTests.cs（+1/-1）
    • CancelInTryAndExitCatchNormally のテスト属性に IsMultithreadingSupported の条件を追加。同クラス内の他の Task.Run を使うテストと同じ扱いに揃えています。

背景として、2つのPRが1分差でマージされたことによる相互作用があります。

  • #135915：IsMultithreadingSupported をクラス単位から、Task.Run でキャンセルする4つの有効なテストへ移動
  • #135939：CancelInTryAndExitCatchNormally を再度有効化。ただしブランチが #135915 より前のため、main上では条件が付いていない状態になった

シングルスレッドのwasmでは、アクションがスピンしている間キャンセル側の Task.Run タスクが実行できず、テストが完了しません。

パフォーマンスへの影響

ライブラリ本体への影響はなく、テストのみの変更です。CIの実行時間については、browser-wasmの LibraryTestsCoreCLR レグにおける System.Runtime.Tests の結果が次のとおりです。

  • #135939 なし：872秒（build 1641014）、972秒（build 1641108）で成功
  • #135939 あり：どちらも5402秒でタイムアウト（build 1641112、1641117）

関連Issue

  • #136116（本PR）
  • 関連PR：#135915、#135939

その他

  • src/libraries 配下で #135939 が変更したのは、このテストの属性のみです。ログからは、実行中だったテストの名前は特定できていません。したがって、このテストが原因というのは推測であり、本PRのCI結果で検証されます。
  • 作成者の記載によれば、本PRはAI（Anthropic Claude、OpenAI Codexによる確認）の支援で準備され、作成者がレビューしたうえで投稿されています。

#136114 [CI] Report compiler cache statistics after runtime test builds

概要

CIパイプラインにおいて、Roslynコンパイラキャッシュの統計レポートが、ランタイムテストのビルド前に出力されていたため、テストのコンパイル分が集計から漏れていました。このPRは、統計レポートのステップをランタイムテストのビルド後へ移動します。キャッシュの設定やビルドの挙動自体は変更されません。

変更内容

  • eng/pipelines/coreclr/templates/jit-hardware-intrinsics-common.yml (+2/-2): 統計レポートのステップ位置を変更
  • eng/pipelines/runtime.yml (+4/-4): 統計レポートのステップ位置を変更
  • 対象は計6つのジョブ定義で、CoreCLR checkedビルド（Linux arm64を含む）、NativeAOT、hardware-intrinsicsのジョブが含まれます。
  • 変更はステップの配置のみで、呼び出し回数は変わりません（作成者による確認）。

パフォーマンスへの影響

影響なし（CIパイプラインのステップ順序の変更のみで、ランタイム/ライブラリの実行性能には関係しません）。

関連Issue

なし

その他

  • 作成者による検証:
    • Linux arm64 Checked設定・分離したRoslynキャッシュでCoreCLRTestLibraryを2回ビルドし、いずれも成功。初回はキャッシュエントリを保存し、2回目は再利用された。
    • 変更した2つのYAMLファイルをパースし、6箇所のステップ順序を確認。
    • git diff --checkは成功。
  • フルのarm64 CIはローカルでは実行されていません。
  • このPRはGitHub Copilotを用いて生成されたと記載されています。

#136112 Add ilverify --list-errors to list the names --ignore-error matches

概要

ILVerify に --list-errors オプションを追加します。--ignore-error / --ignore-error-file は正規表現でエラー名にマッチさせますが、その名前を確認する手段がなかったため、一覧を出力できるようにしました。Issue #136056 では --help --verbose が提案されていましたが、代替案として挙げられていた独立オプションを採用しています。--verbose の意味は従来どおり変わりません。

  • None を除くすべての VerifierError 名を Strings.resx のメッセージ付きで出力
  • すべての ExceptionStringID 名（型システムエラー）を出力
  • 上記どちらの名前も持たないエラーは None にマッチする旨を出力

--help と同様に入力ファイルなしで動作します。入力ファイルを併せて指定した場合は、一覧を出力するのみで検証は行いません。また、メッセージ中の '{0}' などのプレースホルダー（5件）は、実際のエラー報告時に ILVerify が埋めるものであり、一覧では未置換のまま表示されます。

出力例:

Verification errors (--ignore-error matches these names):
  UnknownOpcode: Unknown opcode.
  ...

Type system errors (--ignore-error also matches these names):
  ClassLoadGeneral
  ...

An error with neither kind of name, such as an exception while verifying a method, matches None.

変更内容

  • src/coreclr/tools/ILVerify/ILVerifyRootCommand.cs（+35/-0）
    • --list-errors オプションの追加
    • 通常の --help には --list-errors List the error names that --ignore-error matches の1行が追加される

パフォーマンスへの影響

影響なし（コマンドラインオプションの追加のみで、検証処理自体の変更はなし）。

関連Issue

#136056（Fixes）。PR 番号は #136112 です。

その他

  • ILVerify にはコマンドラインのテストがないため、main ビルドと本ブランチのビルドを比較して手動で検証したとのことです。
    • 入力ファイルなしで終了コード 0、検証エラー名 124件（None を除く全 VerifierError）と型システム名 25件（全 ExceptionStringID）が宣言順に出力される。
    • 通常の --help の差分は追加された1行のみ。
    • ReturnTests アセンブリで --ignore-error "^ReturnPtrToStack$" を指定すると、ReturnPtrToStack の2件のみが除外される。
    • InvalidMetadataReferenceTests で --ignore-error "^ClassLoadGeneral$" を指定すると、ClassLoadGeneral の5件が除外される。
    • ILVerification.Tests は 513/513 件がパス。
  • 作成者によると、本PRは AI（Anthropic Claude と OpenAI Codex）の支援を受けて作成され、作成者がレビュー済みです。

#136109 [Bugfix] Clear removed elements in ImmutableArray<T>.Builder

概要

ImmutableArray<T>.Builder で RemoveRange や RemoveAll などの一括削除を行った後、Count 以降のバッキング配列に削除済みの値が残る不具合を修正するPRです。Count を増やすとその残存値が露出し、「追加された要素は default(T) で初期化される」というドキュメント上の保証に反していました。また、削除された参照がバッキング配列に残り続ける問題もありました。

var builder = ImmutableArray.Create(1, 2, 3, 4).ToBuilder();
builder.RemoveRange(1, 2);
builder.Count = 4;
Console.WriteLine(string.Join(", ", builder));
// 期待値: 1, 4, 0, 0
// 修正前: 1, 4, 3, 4

.NET 9、.NET 10、.NET 11 RC2 で再現が確認されており、以前から存在する問題とのことです。

変更内容

  • ImmutableArray_1.Builder.cs (+2/-10)
    • RemoveRange(int, int) が、参照を含む型で後続要素が残る場合にのみ削除区間を詰め替え前にクリアし、その後 _count を直接変更していました。この誤った位置のクリア処理を削除しました。
    • RemoveAll や列挙型の RemoveRange オーバーロードが使用する RemoveAtRange ヘルパーも、空いた末尾をクリアせずに _count だけを減らしていました。
    • 両方のパスで、要素の詰め替え後に既存の Count セッターを使うよう変更しました（RemoveAt と同じ方式）。これにより、すべての要素型で空いた末尾がクリアされます。
    • 既存の引数検証と no-op 時の挙動は維持されます。
  • ImmutableArrayBuilderTest.cs (+63/-0)
    • 整数型、参照型、参照を含む構造体を対象に、空・先頭・中間・末尾・全削除・非連続削除の各ケースを追加しました。
    • 予備容量がある場合とない場合の両方のビルダーを対象にしています。
    • Count を増やす前の残存内容と、増やした後の default 初期化を検証します。

パフォーマンスへの影響

ベンチマーク結果の記載はありません。Count セッター経由でクリアを行うため、削除後に末尾のクリア処理が実行される点が挙動上の変更です。

関連Issue

なし

その他

  • 公開APIの変更はなく、Count が保証する default(T) 初期化に実装を合わせるバグ修正です。
  • 削除済み参照がバッキング配列に残らなくなるため、参照型の要素が意図せず保持され続ける問題も解消されます。

#136089 [cDAC] Fix incorrect filtering of stack-interior references

概要

ランタイムの一部の経路では、PromoteCarefully を経由せずにスタック内部参照（stack-interior references）を報告するため、cDAC側とランタイム側でフィルタリングが非対称になっていました。比較前に両方の結果からこれらの参照を除外することで、cDAC ストレステストの誤検知（false failure）を防ぎます。作成者によれば、#135959 で失敗していたCIパイプラインへの対処であり、本PRはcodexの支援で作成されています。

変更内容

  • src/coreclr/vm/cdacstress.cpp（+12/-5）
    • cDAC側とランタイム側の双方の結果から、スタック内部参照をフィルタリングしてから比較するように変更

パフォーマンスへの影響

影響なし（ストレステスト用の比較ロジックの修正であり、通常のランタイム実行パスへの影響に関する記載はありません）

関連Issue

  • #135959（失敗していたCIパイプラインの元となるPR。作成者の記述より）

その他

  • 公開APIの変更や互換性への影響に関する記載はありません。
  • レビュー依頼先: @dotnet/arm64-contrib, @dhartglassMSFT, @max-charlamb

#136072 Restart HttpListener authentication when protection policy changes

  • 作成者: @rzikm
  • 作成日時: 2026年10月19日 08:36:18(UTC)
  • マージ日時: 2026年10月20日 18:02:08(UTC)
  • ラベル: area-System.Net.Http

概要

HttpListener の拡張保護（extended protection）セレクタがNTLMハンドシェイクの途中でポリシーを変更した場合、従来は400を返していました。Windows Server 2019 (RS5) では、古いコンテキストが破棄され、その継続トークンが新しいコンテキストに渡されて InvalidToken が返り、マネージド側のクライアント障害マッピングが400を選択していたためです。

本PRでは、進行中の同一パッケージのコンテキストがポリシー非互換になった場合に、401と新しいチャレンジで認証を再開するよう変更しています。古いコンテキストは、弱いポリシーのまま再利用せず、切り離して破棄します。新規の不正トークンに対する既存のマッピング（400）は変更されません。

変更内容

  • src/libraries/System.Net.HttpListener/src/System/Net/Windows/HttpListener.Windows.cs (+10/-0): ポリシー非互換になった進行中コンテキストを検出し、古いコンテキストを切り離して破棄したうえで、401と新しいチャレンジで認証を再開する処理を追加。
  • src/libraries/System.Net.HttpListener/tests/HttpListenerAuthenticationTests.cs (+4/-2): 既存の回帰テストに、Never/Never認証の成功と未認証の厳格ポリシー拒否に加えて、素の WWW-Authenticate: NTLM による再開チャレンジの確認を追加。

パフォーマンスへの影響

影響なし

関連Issue

#135190（本PRで解決）

その他

  • 作成者の記載によるテスト結果:
    • ローカルのテスト実行: 688 passed、0 failed、8 skipped。資格情報が必要な回帰テストはローカルではスキップされ、不正なNTLM/Negotiateトークンのケースは想定どおり400を維持。
    • NativeAOTビルドも成功。
    • RS5（SYSTEM権限）では、修正前は400で失敗し、修正後は10回すべて成功（ポリシー不変の対照も成功）。
    • RS5での通常スイートは696 passed、0 failed、12 skipped。
    • RS5のCoreCLR対照実験では、10組のrelaxed/strictペアで、認証済みが204、未認証が新しいNTLMチャレンジ付きの401。
  • 作成者によると、詳細なコンテキスト/SSPIトレースは、NativeAOTの計装実行ではなくこのCoreCLR対照実験から取得したものです。
  • PR説明とコード変更はGitHub Copilotによって生成されたと記載されています。

#136063 Make whole-list ImmutableList<T>.Reverse() O(n)

概要

ImmutableList<T>（およびそのBuilder）の全体反転 Reverse() が、これまでO(n log n)のインデックス指定スワップで実装されていた点を、ツリーをミラーリングする方式に変更し、各ノードを1回だけ訪問するO(n)にしています。AVLバランスは維持されます。部分範囲の反転は従来のまま変更されていません。

実装は次の方針です。

  • コピーオンライトで、frozen（凍結）済みの内部ノードはクローンし、リーフは再利用する
  • 未凍結のBuilderノードはその場で反転する
  • 全範囲を対象とするオーバーロードのみ、この経路を通す

変更内容

  • ImmutableList_1.Node.cs（+15/-1）: ツリーをミラーリングして全体を反転する処理を追加し、全範囲のオーバーロードをこの経路に接続
  • ImmutableListBuilderTest.cs（+50）: Builder向けテストを追加
  • ImmutableListTest.cs（+31）: 全リスト反転の境界、バランス、インデックスアクセス、スナップショット保持のテストを追加
  • ImmutableListTestBase.cs（+1/-1）: 軽微な修正

パフォーマンスへの影響

作成者によるローカルのBenchmarkDotNet（ShortRun）結果（100,000要素）：

操作 変更前 変更後
Immutable list 17.16 ms 1.23 ms
Frozen builder 15.85 ms 1.01 ms
Mutable builder 15.68 ms 0.437 ms
  • Immutable listのアロケーションは 4.80 MB から 3.15 MB に減少
  • 計算量の改善（O(n log n)→O(n)）により、大きなリストほど効果が大きくなる見込みです

関連Issue

#136030（このPRで修正）

その他

なし

#136050 [wasm][R2R] Fix calls through MethodImpl-redirected slots on portable entrypoints

概要

Wasm（portable entrypoints）のR2R環境で、同一型の .override（MethodImpl）によってリダイレクトされたvtableスロットを経由する呼び出しが、実装ではなく宣言側メソッドを実行・準備してしまう問題を修正します。非portableターゲットでは宣言のvtableスロットが実装のentrypointを保持するため問題になりませんが、portable entrypointsでは以下の3つの経路で宣言側が処理されていました（self_override5で再現）。

  • ExternalMethodFixupWorker: スロットを読む前に宣言側をprestubしており、宣言自身のR2Rボディを公開し、Checkedビルドでassertしていました。修正後は、スロットを読み、そのentryを所有するメソッドを準備して、セルをそれでパッチします（非portable分岐と同様）。
  • ExecuteInterpretedMethodWithArgs_PortableEntryPoint_Complex（R2R → インタープリタ）: 宣言側を準備・実行していました（例: 名前で宣言にバインドされたdelegate）。修正後は、PrepareInterpreterCode と同様に、先に宣言→実装のマッピングを行います。
  • 同entryの早期パス: 実装のインタープリタコードが宣言側に格納されている場合にCheckedでassertしていました（既存の問題）。修正後は、そのコードを所有するメソッドとして実行します。

変更内容

  • src/coreclr/vm/prestub.cpp（+25/-10）: 上記3経路の修正。
  • src/tests/Loader/classloader/MethodImpl/Desktop/self_override5.il（+0/-1）: #134949 に起因するquarantine（除外設定）を削除。

パフォーマンスへの影響

影響なし（正確性の修正であり、性能に関する記載はありません）。

関連Issue

#134949（部分的に対応）

その他

  • もう一方の #134949 の失敗（overflow0[1-4]_div）は、インタープリタ実行のCoreLibでR2Rコードを動かした場合にのみ発生します。レビューでこれは未サポートと整理されたため、これらのquarantineは維持されます。
  • CallDescrWorkerInternal のportableパスも、マッピングなしでprestubを行います。再現は未確認で、今後のフォローアップ候補です。
  • 検証: WASI（Checkedランタイム、wasmtime）で、R2R版CoreLibとCI構成の両方において、MethodImplテスト、CovariantReturns テスト20件、jit64_5 がR2RおよびインタープリタでPASSしました。ブラウザおよびReleaseランタイムビルドは未検証です。

#136040 JIT: inline box Nullable<T> in ReadyToRun

  • 作成者: @lewing
  • 作成日時: 2026年10月18日 23:22:38(UTC)
  • マージ日時: 2026年10月20日 01:39:05(UTC)
  • ラベル: area-CodeGen-coreclr

概要

ReadyToRun（R2R）コードで CORINFO_HELP_BOX_NULLABLE のインライン展開を有効化する変更です。クラスハンドルを直接埋め込む代わりに、box T と同じ経路（基底型のトークン経由）でアロケーションを行います。これにより、既存のエスケープ解析が対象となるヒープ割り当てを除去できるようになります。

作成者によると、box int? は browser-wasm および tiering なしのネイティブ R2R でおよそ 30 倍高速化されたとのことです。ios 系ターゲットは CoreCLR を composite R2R として公開するため同じコード生成になりますが、実機での計測は行われていません。

変更内容

  • src/coreclr/jit/importer.cpp（+17/-8）
    • ReadyToRun のボックス化を、基底型に対する解決済みトークン経由のアロケーションで行うよう変更
    • 既存の JIT / NativeAOT のアロケーション経路と、共有ジェネリックのフォールバック経路は維持

パフォーマンスへの影響

  • box int? が browser-wasm および tiering なしのネイティブ R2R で約 30 倍高速化（作成者による報告）
  • ios 系ターゲットは同じコード生成になる見込みだが、実機では未計測

関連Issue

なし

その他

  • Copilot のレビュー概要では「要確認」と評価されています。合成されたトークンとプラットフォーム固有の ReadyToRun fixup について、モジュール間の解決とバージョニングの挙動をメンテナが確認する必要があるとされています。
  • レビュー概要によれば、ビルドやテストは実行されていません。

#136033 ilverify: respect IgnoresAccessChecksToAttribute

概要

ILVerify が IgnoresAccessChecksToAttribute を尊重するようになり、ランタイムと同様にこの属性が付与するアクセス権を許可します（#130959 の修正）。通常の可視性チェックの後（最後）に判定され、属性が公開鍵を指定している場合のみ公開鍵の一致が要求されます。

変更内容

  • src/coreclr/tools/ILVerification/AccessVerificationHelpers.cs: 通常の可視性チェック後に属性ベースのアクセス判定を追加。公開鍵トークンの比較ロジックを再利用。
  • src/coreclr/tools/ILVerification/ILVerifyTypeSystemContext.cs、Verifier.cs: 属性対応のための関連変更（詳細は提供情報からは不明）。
  • src/coreclr/tools/ILVerify/ILVerifyRootCommand.cs、Program.cs: ILVerify ツール側の関連変更（詳細は提供情報からは不明）。
  • src/coreclr/tools/ILVerification.Tests/ILTests/AccessTestsIgnoreChecks.il / .ilproj: private アクセスと公開鍵不一致を検証する新規テストフィクスチャを追加。
  • src/coreclr/tools/ILVerification.Tests/ILMethodTester.cs、TestDataLoader.cs: 新規テストを実行するためのテスト基盤の調整。

作成者によると、新規の AccessTestsIgnoreChecks テストは main では失敗し、修正後は成功します。

パフォーマンスへの影響

影響なし（提供情報にパフォーマンスに関する記載はありません）。

関連Issue

#130959

その他

Copilot のレビューでは「変更推奨」とされ、以下の2点が未解決として指摘されています。

  • （高） 属性が参照するフレンドアセンブリのアイデンティティ項目の検証が CoreCLR と異なるため、アクセスを許可する前にこれらの項目を検証すべき。
  • （中） 公開鍵不一致の否定テストで使用している鍵が無効なアイデンティティであり、有効で異なる公開鍵を使うべき。

なお、Copilot による検証はソース確認と属性 blob のデコードに限られ、ビルドやテストは実行されていません。

#136021 JIT: keep lea esp, [ebp] in x86 epilogs

概要

x86 JITのエピローグで lea esp, [ebp] を mov esp, ebp に書き換えないよう修正するPRです。#135793 で「変位0・ベースのみのLEAをレジスタ移動に書き換える」最適化が入りましたが、AMD64では rsp, [rbp] が例外になっていた一方、x86には同じ例外がありませんでした。

  • localloc を使い、EBP以外のcallee-saved registerをpushしないメソッドは、エピローグで lea esp, [ebp-0] によりESPを復元します。
  • x86のGC-infoエピローグデコーダ（gc_unwind_x86.inl の UnwindEbpDoubleAlignFrameEpilog）は、checkedビルドでこの命令のバイト列を検証し、変位0の場合は3バイトをスキップします。cDACの X86Unwinder も同様です。
  • #135793 後は mov esp, ebp が出力されるため、このようなエピローグでスレッドがGCサスペンドのhijackを受けると、checkedランタイムが SKIP_LEA_ESP_EBP でassertします。windows-x86 checkedの System.Text.Json.Tests と System.Runtime.Tests で発生したとのことです（詳細は #136020）。

変更内容

  • src/coreclr/jit/emitxarch.cpp
    • emitter::emitIns_R_ARX のスタックポインタ/フレームポインタの例外を、AMD64限定ではなく全xarchターゲットに適用します。これにより lea esp, [ebp] がそのまま出力されます。
    • コメントにx86側の利用箇所（デコーダ）を明記しています。
  • src/tests/JIT/Regression/JitBlue/Runtime_135793/Runtime_135793.cs
    • localloc を使う2つのメソッドに対する、disasmテスト（HasDisasmCheck）です。x86では lea esp, [ebp] の直後に pop ebp が続くことを確認します。
  • src/tests/JIT/Regression/JitBlue/Runtime_135793/Runtime_135793.csproj
    • 上記テストのプロジェクトファイルです。

検証結果（作成者による、linux-x64上でのクロスターゲット検証）:

  • 修正前: エピローグは mov esp, ebp / pop ebp / ret となり、disasmチェックは失敗します。
  • 修正後: エピローグは lea esp, [ebp] / pop ebp / ret となり、チェックが通ります。
  • AMD64には既に同じ例外があるため、x64コードへの影響はありません。同じメソッドのx64の出力は、サイズ・命令数・PerfScoreとも修正前後で同一とのことです。

パフォーマンスへの影響

影響なし。x64の出力はサイズ・命令数・PerfScoreとも変化しません。x86では特定のエピローグ（localloc使用時のESP復元）の命令が mov esp, ebp から lea esp, [ebp] に戻るのみです。

関連Issue

#136020（修正対象）。原因となった変更は #135793 です。

その他

  • 実際のWindows x86ランタイムでの実行は未確認で、このPRのwindows-x86 checkedのCIレグで検証される予定です。
  • 作成者の記載によれば、本変更はAI支援（Anthropic Claude、OpenAI Codexによる確認）で準備され、作成者がコードとdisassemblyを確認したとのことです。

#136006 [wasi] Set RUNTIME_IDENTIFIER and ENTRY_ASSEMBLY_NAME in wasihost

概要

CoreCLR の WASI ホスト（wasihost）が RUNTIME_IDENTIFIER を設定していなかったため、RuntimeInformation.RuntimeIdentifier が "unknown" を返していた問題を修正します。ホストが wasi-wasm（Mono の WASI ドライバーと同じ値）を設定するようになり、あわせて ENTRY_ASSEMBLY_NAME も corerun や hostpolicy と同様に get_runtime_property から提供されます。また、#134964 で追加された runtimeconfig.bin リーダーを堅牢化しています。

変更内容

  • src/native/corehost/wasihost/wasihost.cpp
    • RUNTIME_IDENTIFIER（wasi-wasm）を設定
    • ENTRY_ASSEMBLY_NAME を get_runtime_property から返すように変更
    • runtimeconfig.bin リーダーの堅牢化：ファイルが存在しない場合のみ無視し、それ以外のオープン失敗は起動を停止（従来は全 feature switch が黙って破棄され得た）。末尾に余分なデータがある場合は拒否
  • RuntimeIdentifierTests.cs
    • VerifyWasiRid テストを追加（ホスト側の変更がないと失敗する）
  • System.Runtime.InteropServices.RuntimeInformation.Tests.csproj
    • これまで WASI では実行されていなかったため、-wasi ターゲットを追加

パフォーマンスへの影響

影響なし

関連Issue

  • #134964（runtimeconfig.bin リーダーの導入元。本 PR で堅牢化）
  • #134952（APP_CONTEXT_BASE_DIRECTORY はこのレイアウト決定を待つため本 PR では未対応）

その他

  • 作成者によると、本 PR は GitHub Copilot の支援を受けて作成されています。

#135991 [wasm] Fix single-register struct call result stores (narrow stores, GC write barrier)

概要

Wasmにおいて、単一レジスタで返される構造体の呼び出し結果ストア（LowerStoreSingleRegCallStruct）が、構造体のWasm ABI型（4バイト未満の構造体やオブジェクト参照をラップする構造体では i32）に型を変更していた問題の修正です。

この問題により、Half や1バイト構造体のストアが4バイト書き込みとなって隣接領域を破壊していました（インプレースの TensorPrimitives.Tan<Half> で次の入力がゼロになる）。また、オブジェクト参照のストアではGC write barrierが失われていました（Wasmのオブジェクトは現状gen0に留まるため、現時点では実害なし）。

修正は LoongArch64/RISC-V64 と同じルールを採用し、構造体自身のレジスタ型を維持しつつ、float戻り値の場合のみ呼び出しの型を採用します。

変更内容

  • src/coreclr/jit/lower.cpp: LowerStoreSingleRegCallStruct のストア型決定ロジックを修正（+7/-9）
    • 小さな構造体は i32.store8 / i32.store16 を使用
    • オブジェクトフィールドは CORINFO_HELP_CHECKED_ASSIGN_REF を使用
    • それ以外のストアは変更なし（struct { float } / struct { double } は f32.store / f64.store、struct { long } は i64.store、struct { Vector128<int> } は v128.store）
    • Int128 は隠しリターンバッファを使用するため影響なし
  • src/libraries/System.Numerics.Tensors/tests/Helpers.cs, TensorPrimitives.Generic.cs, TensorTests.cs: この問題のために無効化されていた3つのTensorsテストを再有効化（計 -9行）
  • src/tests/JIT/Regression_ro_2/Runtime_135117.cs: 回帰テスト Runtime_135117 を追加（+206行）

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）。SuperPMIのdiffsが添付されています。

関連Issue

#135117（本PRで解決）

その他

  • Runtime_135117 は、元のJITではWASIのReadyToRunで失敗し、修正後は成功するとのことです。
  • CIのWASIランタイムテストのサブセットには Regression_ro_2 が含まれていません。
  • #129555 の挙動（float/doubleのストア）は維持されます。

#135983 [browser] Make SystemJS_GetLocaleInfo argument order consistent

概要

SystemJS_GetLocaleInfo は C およびマネージド interop 側では (locale, culture, ...)（記述対象のロケール、次に表示言語）と宣言されていますが、TypeScript 実装と CoreLib の呼び出し側は (culture, locale, ...) の順で使っていました。リポジトリ内では両者の入れ替わりが打ち消し合って動作していましたが、宣言どおりに呼び出すと結果が誤っていました（例：fr-FR を en-US で記述すると anglais##États-Unis が返る）。

本PRは TypeScript 側のパラメータ順を宣言に合わせ、JSGetLocaleInfo / JSGetNativeDisplayName とその呼び出し元を更新します。リポジトリ内の動作は変わりません。

変更内容

  • src/libraries/System.Private.CoreLib/src/System/Globalization/CultureData.Browser.cs: JSGetLocaleInfo / JSGetNativeDisplayName とその呼び出しの引数順を修正
  • src/libraries/System.Private.CoreLib/src/System/Globalization/CultureData.Icu.cs: 上記に合わせて呼び出し側を更新
  • src/mono/browser/runtime/globalization-locale.ts: TS 実装のパラメータ順を (locale, culture, ...) に変更
  • src/native/libs/System.Native.Browser/native/globalization-locale.ts: 同上

パフォーマンスへの影響

影響なし

関連Issue

#135439

その他

  • 内部実装（ブラウザ向けのグローバリゼーション interop）の引数順の整合性修正であり、公開APIの変更はありません。
  • リポジトリ内の動作は変わらないとされています。
  • PR説明は GitHub Copilot により生成されたものです。

#135968 [release/11.0] cDAC: skip empty assembly-list slots in Loader_1.GetModuleHandles

概要

release/11.0 に #135519 をバックポートするPRです。cDACの Loader_1.GetModuleHandles は、コレクティブルなアセンブリがアンロードされた際にAppDomainのアセンブリリストへ残る空スロットで例外をスローしていました。本PRはネイティブDACと同様に、このような空スロットをスキップするよう修正します。プロダクトコードの変更はnullチェックのみです。

変更内容

  • src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/Loader_1.cs (+4/-0): 空スロットをスキップする処理を追加
  • docs/design/datacontracts/Loader.md (+7/-1): 疑似コードを更新
  • src/native/managed/cdac/tests/UnitTests/LoaderTests.cs (+35/-0): 新規テスト GetModuleHandles_SkipsEmptySlots を追加
  • src/native/managed/cdac/tests/UnitTests/MockDescriptors/MockDescriptors.Loader.cs (+51/-0): 新テストに必要なモックAppDomainのサポートを追加（#135516 由来）

自動バックポートはテストファイル2件でコンフリクトしました（release/11.0 に #135516 がないため）。そのため、新規テストと必要なモックサポートのみを追加しています。#135516 自体の修正とテストは含まれません。

影響範囲と互換性:

  • cDAC（診断用データコントラクトリーダー）の内部実装の修正であり、公開APIの変更や破壊的変更はありません。
  • 修正前は、GetModuleHandles を利用するAPIが失敗していました（例: ISOSDacInterface.GetAssemblyList が、アセンブリを返さず失敗のHRESULTを返す）。修正後は、残りのモジュールが返されます。
  • この問題はコードを読んで発見されたもので、実プロセスやダンプでの再現は行っていません。
  • リグレッションではありません。GetModuleHandles は元々（#114800 で追加、当時は GetModules、#117452 でリネーム）空スロットをスキップしていませんでした。

パフォーマンスへの影響

影響なし

関連Issue

  • #135519（元のPR）
  • #135518（コード調査で問題を発見したIssue）
  • #135516（モックAppDomainの追加元）
  • #114800、#117452（ループの追加とリネーム）

その他

  • リスクは低いです。プロダクトの変更は、ネイティブのイテレータ（AppDomain::AssemblyIterator::Next_Unlocked）と同様に空スロットをスキップするnullチェックのみです。
  • テスト結果: linux-x64、osx-arm64、windows-x64で Microsoft.Diagnostics.DataContractReader.Tests の3098件がすべて成功しました。Loader_1.cs を release/11.0 の版に戻すと、新規テストの4ケースのみが VirtualReadException で失敗し、テストが不具合を検出できることを確認しています。
  • 作成者の記載によると、このPRはAI（Anthropic Claude、OpenAI Codexによる確認）の支援で作成され、作成者がレビュー済みです。

#135956 Simplify frozen object heap allocation

概要

NativeAOT における Frozen Object Heap の割り当て実装を簡素化するPRです。プラットフォーム固有の仮想メモリ操作（reserve/commit/mprotect）を廃止し、共有のゼロ初期化済みネイティブ割り当てに置き換えます。作成者によれば、この機能は CoreCLR VM に比べて使用頻度が低いため、実装を単純化できるとのことです。Copilot の概要では、これにより WASM 上でも NativeAOT の frozen object 割り当てが有効になるとされています。

変更内容

  • FrozenObjectHeapManager.cs: セグメント割り当てを共有のゼロ初期化済みネイティブ割り当てに書き換え、初期セグメントサイズを小さくしました（+13/-71）。
  • FrozenObjectHeapManager.Unix.cs / FrozenObjectHeapManager.Windows.cs: プラットフォーム固有の仮想メモリヘルパーを削除しました。
  • System.Private.CoreLib.csproj: 上記ファイルのプロジェクト参照（5行）を削除しました。
  • Interop.MProtect.cs: 不要になったマネージド側の MProtect interop を削除しました。
  • Reflection.cs（SmokeTests）: 動的に生成された配列型について、強制 GC をまたいだランタイム型の同一性と rank を検証するテストを追加しました（+32）。

パフォーマンスへの影響

ベンチマーク結果は提供されていません。メモリ確保方式（仮想メモリの reserve/commit からゼロ初期化済みネイティブ割り当てへ）と初期セグメントサイズが変わるため、メモリ使用の挙動に影響する可能性がありますが、具体的な数値は不明です。

関連Issue

なし

その他

  • Copilot のレビューで中程度の指摘が1件あります。アロケータの書き換えが、PR の意図とされる WASM 向けの範囲を超えてデスクトップ環境のメモリポリシーも変更しており、デスクトップでの検証が示されていない、という内容です。ゼロ初期化セグメント割り当ての変更を WASM に限定することが提案されています（該当レビューコメント）。
  • 本PRは Copilot により「変更推奨（Changes recommended）」と評価されています。

#135952 Resolve WASI SDK for NativeAOT runtime test builds

概要

NativeAOT の WASI 向けランタイムテストのビルドで、共有の WASI SDK を解決できるようにする変更です。AcquireWasiSdk.targets をインポートし、NativeAOT の OS 固有リンカー設定より前に WASI_SDK_PATH を設定します。グループ化されたテストビルドは別々の MSBuild プロセスで実行され、外側のターゲットで計算されたプロパティを継承しないため、この処理は各テストプロジェクトで行われます。あわせて、Unix 用の rpath リンカー引数から WASM を除外します。

変更内容

  • src/tests/Directory.Build.targets (+12/-1)
    • NativeAOT の WASI テストで AcquireWasiSdk.targets をインポートし、WASI_SDK_PATH を設定
    • テストインフラの Unix rpath リンカー引数から WASM を除外

パフォーマンスへの影響

影響なし（ビルド/テストインフラの変更であり、ランタイムの性能に関する記載はありません）

関連Issue

なし

その他

  • 本 PR の検証は、未マージの他の有効化変更を含むローカルの NativeAOT WASI ブリングアップ環境で行われています。
    • nativeaot\SmokeTests\AttributeTrimming\AttributeTrimming.csproj のビルドに成功しました（テスト成果物の削除後も成功）。Wasmtime 上で終了コード 100 で実行されました。
    • nativeaot wasm wasi の tree ビルドはテストのコンパイル/リンクまで進みましたが、既存の UnitTests の lowering アサーションで失敗しています。C の数学 ABI 警告も残っています。
  • このブランチは main から cherry-pick した 1 コミットのみを含み、単独ではビルドされていません。
  • 自動実行の統合と Unix ホストでの検証は含まれていません。

#135893 JIT: Gate single-edge root profile trust on hotness or speed preference

  • 作成者: @EgorBo
  • 作成日時: 2026年10月15日 20:23:24(UTC)
  • マージ日時: 2026年10月20日 14:01:28(UTC)
  • ラベル: area-CodeGen-coreclr

概要

FullOpts のルートメソッドに対して「単一エッジの合成プロファイル（synthetic profile）を信頼する」処理を、メソッドの hotness またはスピード優先の指定がある場合に限定する JIT の変更です。すべての FullOpts ルートでこのプロファイルを信頼すると、短命な動的メソッドへの過剰なインライン化が起こり、LambdaExpression.Compile() が大幅に遅くなっていたため、これを修正します（#127203 の修正）。

以下のいずれかの条件を満たす場合のみ、既存の合成ルートプロファイルのロジックを維持します。

  1. メソッドに [MethodImpl(MethodImplOptions.AggressiveOptimization)] が付いている
  2. JIT_FLAG_SPEED_OPT が設定されている（例: NativeAOT を prefer-speed でコンパイルした場合）
  3. Tier0 または ReadyToRun からの昇格後に JIT_FLAG_TIER1 が設定されている

変更内容

  • src/coreclr/jit/fgprofilesynthesis.cpp（+7/-5）: 単一エッジのルートプロファイルを信頼する条件に、上記3つの条件によるゲートを追加

インライン対象（inlinee）の挙動は従来どおりです。実際の PGO、および既存の cctor・サイズ・呼び出し回数による除外条件も変更ありません。

パフォーマンスへの影響

作成者による計測結果です（現行 main（.NET 12-dev）の Release ビルド、Windows x64、Ryzen 7950X、TieredPGO 有効、差分は clrjit.dll のみ）。

再現ケース 修正前 修正後 改善
EntityGraphQL Compile() 7.611 ms 0.352 ms 21.6倍高速
EntityGraphQL Compile(preferInterpretation: true) 2.578 µs 2.495 µs ほぼ変化なし
LINQ-stub 再現（クエリあたり） 5.823 ms 0.777 ms 7.5倍高速
  • EntityGraphQL は元のベンチマークソースを使用し、BenchmarkDotNet の平均値（計測イテレーション8回）を採用しています。
  • 未改変の LINQ-stub プログラムは、バージョンごとに2回起動し、ウォーム状態のラウンド（1ラウンド2,000クエリ）の中央値を採用しています。

関連Issue

#127203

その他

なし

#135863 corehost: singlefilehost fixes for OpenHarmony

概要

OpenHarmony（OHOS）向けに singlefilehost（静的 apphost）をビルドできるようにするための CMake 修正です。OHOS 上では NATIVE_LIBS_EMBEDDED と System.Net.Security.Native-Static をスキップし、runtimeinfo のリンクを $<LINK_LIBRARY:WHOLE_ARCHIVE> ジェネレーター式ではなく明示的な whole-archive リンカーフラグで行うよう変更しています。作成者によれば、この式は OpenHarmony NDK ツールチェーンでは使用できないためです。

変更内容

  • src/native/corehost/apphost/static/CMakeLists.txt（+13/-6）
    • OHOS では NATIVE_LIBS_EMBEDDED を扱わない条件分岐を追加
    • OHOS では System.Net.Security.Native-Static へのリンクをスキップ
    • OHOS では runtimeinfo を明示的な whole-archive フラグでリンク

パフォーマンスへの影響

影響なし（ビルド構成の変更のみで、ベンチマーク結果の記載もありません）。

関連Issue

なし

その他

  • 作成者のテスト内容は、openharmony-arm64 向けに静的 apphost をクロスビルドし、シングルファイルアプリを publish するというものです。
  • Copilot のレビューでは、以下の指摘がありました。
    • 1回目のレビューで、「embedded natives の無効化により圧縮バンドルの展開が壊れる」（High）と、「メタデータ変更時に runtimeinfo ターゲットがホストを再リンクしない」（Medium）という指摘があり、いずれも 2回目のレビュー時点で解決済みとされています。
    • 2回目のレビューでは、OpenHarmony の sysroot に GSSAPI がない場合、セキュリティ依存関係の探索ブロックが依然として構成を妨げるという指摘（High）が未解決で残っています。OHOS をこのブロックから除外することが推奨されています。また、クロスビルドと publish の検証は実行されていないとされています。

#135853 JIT: spill local refs for COMMA-wrapped local stores in impAppendStmt

  • 作成者: @EgorBo
  • 作成日時: 2026年10月15日 09:45:40(UTC)
  • マージ日時: 2026年10月20日 17:40:24(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITのimporterにおいて、クラス初期化ヘルパーのCOMMAでラップされたローカル変数ストアを impAppendStmt が認識できず、スタック上の保留中ローカル参照がspillされないため、構造体のタプルスワップで旧値ではなく新値が読み込まれる不具合を修正します。

ブロック先頭（impLastStmt == nullptr）では、impStoreStruct が構造体ストアをクラス初期化ヘルパーのCOMMAの下に沈めます（例：静的構造体フィールドへの starg）。従来の impAppendStmt は、ステートメントのルートがローカルストアである場合のみをローカルストアとして扱っていました。本修正ではCOMMAを辿って格納先のローカルを特定します。

変更内容

  • src/coreclr/jit/importer.cpp（+4/-4）: ローカル変数ストアの判定でCOMMAを辿り、格納先ローカルを特定するよう変更（Copilotの概要によれば gtEffectiveVal() を使用）。
  • src/tests/JIT/Regression_ro_2/Runtime_135809.cs（+36/-0）: 静的構造体フィールドとクラス初期化を含むタプルスワップが元の値を保持することを検証する回帰テストを追加。

パフォーマンスへの影響

影響なし（diffsもなし）。

関連Issue

その他

  • Copilotのレビュー概要では、修正自体は妥当に見えるものの、checked runtimeでのTier0およびFullOptsにおける検証は未確認とされています。
  • 影響範囲はJITコンパイラの内部実装（importer）であり、公開APIや互換性への影響に関する記載はありません。

#135837 JIT: ignore finally-entry backedges when fixing continuation weights

  • 作成者: @EgorBo
  • 作成日時: 2026年10月15日 01:54:52(UTC)
  • マージ日時: 2026年10月20日 13:55:24(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITの importer.cpp において、finallyハンドラのcontinuation（BBJ_CALLFINALLY とペアになる継続ブロック）の重みを修正する処理で発生していたnull参照を修正します。finallyハンドラには callfinally 以外の通常のバックエッジ（ループなど）を持つ先行ブロックが存在し得ますが、これらがフィルタされないままペアのcontinuationにアクセスしていました。そのため、callfinally 以外の先行ブロックを処理前に除外するようにしています。EH-edgeの構築時のフィルタ方法と揃える形です。

変更内容

  • src/coreclr/jit/importer.cpp（+5/-0）: continuationにアクセスする前に、BBJ_CALLFINALLY 以外の先行ブロック（finallyエントリへの通常のバックエッジ）をスキップする処理を追加。
  • src/tests/JIT/Regression_ro_2/Runtime_135819.cs（+33/-0）: finallyハンドラ内に無限ループを持つ回帰テストを追加。報告されたクラッシュのシナリオを再現するものです。

パフォーマンスへの影響

影響なし（クラッシュ修正のみ。PR作成者によると diffs も差分なし）。

関連Issue

#135819（本PRで修正）

その他

  • Copilotのレビューでは未解決の指摘は0件ですが、プロファイル重み付きコンパイル下での回帰テストの実行が未検証であり、人間による確認が必要とされています。
  • 修正はJIT内部の実装に限定され、公開APIや互換性への影響に関する記述はありません。

#135823 JIT: preserve null checks when folding ThrowIfNull in Tier0

  • 作成者: @Copilot
  • 作成日時: 2026年10月14日 22:29:35(UTC)
  • マージ日時: 2026年10月20日 14:02:16(UTC)
  • ラベル: area-CodeGen-coreclr

概要

Tier0 において ArgumentNullException.ThrowIfNull(r.Ref) のように CORINFO_HELP_BOX が畳み込まれる際、構造体の読み取りが削除され、null の byref に対して NullReferenceException がスローされなくなる問題の修正です。インポーターで、null の可能性があるソースアドレスに対して GT_NULLCHECK を保持するようにし、paramName の評価より前に null チェックが行われるようにしています。

変更内容

  • src/coreclr/jit/importercalls.cpp (+8/-3)
    • CORINFO_HELP_BOX の畳み込み時に、null の可能性があるソースアドレスに対して GT_NULLCHECK を保持するよう変更（paramName の評価より前）。
  • src/tests/JIT/Regression_ro_2/Runtime_135822.cs (+77/-0)
    • Tier0 で分離して実行される回帰テスト（theory）を追加。null の byref と有効な byref の両方、さらに引数の評価順序と副作用を検証。

パフォーマンスへの影響

影響なし（提供情報にベンチマーク結果の記載はなく、diffs でも差分なしとされています）。

関連Issue

#135822

その他

なし

#135731 Merging internal commits for release/8.0

概要

release/8.0ブランチへ内部コミットをマージするPull Requestです（#135731、作成者: dotnet-release-bot[bot]）。

作成者・Copilotによる概要、および変更ファイルの情報が提供されていないため、具体的な変更の目的や技術的内容は判断できません。タイトルからは、リリース用に内部リポジトリのコミットを公開ブランチへ取り込む定型的な作業とみられますが、個別の修正内容（セキュリティ修正の有無など）は記載がなく不明です。

変更内容

変更ファイルの情報が提供されていないため、記載できません。

パフォーマンスへの影響

提供された情報からは判断できません（ベンチマーク結果などの記載なし）。

関連Issue

なし

その他

  • 変更ファイル一覧が空のため、ランタイム/コンパイラ/ライブラリのどの部分に影響するか、互換性への影響（破壊的変更など）、CVE番号の有無はいずれも確認できません。
  • 詳細は、PR本体のコミット一覧や差分を直接確認する必要があります。

#135727 Merging internal commits for release/8.0

概要

release/8.0 ブランチに対して内部コミットをマージするPull Request（#135727）です。作成者は dotnet-release-bot[bot] で、リリース作業の一環として自動作成されたものと見られます。

提供された情報には、作成者による概要・Copilotによる概要・変更ファイル一覧のいずれも含まれておらず、具体的な変更内容や技術的な詳細は確認できません。

変更内容

変更ファイルの情報が提供されていないため、具体的な変更内容は不明です。タイトルからは、内部コミットを release/8.0 にマージする内容であることのみが読み取れます。

パフォーマンスへの影響

影響なし（提供情報からはパフォーマンスに関する変更は確認できません）

関連Issue

なし

その他

  • 本要約はPRタイトルと作成者情報のみに基づいています。
  • セキュリティ修正、バグ修正、互換性への影響の有無などは提供情報からは判断できません。
  • 変更ファイルの一覧や差分が提供されれば、より具体的な要約が可能です。

#135653 Load CoreCLR browser-WASM PDBs into memory instead of the VFS

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年10月13日 00:18:23(UTC)
  • マージ日時: 2026年10月20日 16:04:01(UTC)
  • ラベル: area-Host

概要

CoreCLRのbrowser-WASMホストが、PDBをEmscriptenの仮想ファイルシステム(VFS)ではなく、アセンブリと同様にリニアメモリ上に登録するよう変更されました。これによりJavaScriptのファイルシステムサポートへの依存が不要になり、MonoのbrowserWASMにおけるシンボル読み込み方式とも揃います。

スタックトレースでファイル情報が要求された際、CoreCLRは保持されているCodeViewエントリからポータブルPDBのファイル名を遅延的に特定し、既存の外部アセンブリプローブ経由でホストに問い合わせます。取得したPDBは Module::SetInMemorySymbolStream によってモジュール所有のシンボルストリームとしてキャッシュされます（SetSymbolBytes に伴う動的シンボル通知を回避するため）。

変更内容

  • src/coreclr/vm/debugdebugger.cpp (+92/-0): スタックトレースのファイル情報要求時に、CodeViewエントリからPDBファイル名を取得し、ホストをプローブしてインメモリのシンボルストリームをキャッシュする処理を追加。WebCILは CodeView 情報を保持するため既存のPDB命名規則（WindowsおよびUnixのビルドパスを含む）で検索。シンボルのないWebCILフレームでは、マネージドPEリーダーへのフォールバックをスキップ（未サポート形式の例外が後続フレームのシンボル検索を中断するのを防ぐため）。
  • src/native/libs/Common/JavaScript/host/assets.ts (+23/-16) および src/native/libs/Common/JavaScript/loader/assets.ts (+1/-1): PDBバイトをVFSではなくリニアメモリに登録し、外部アセンブリプローブから参照できるように変更。
  • src/libraries/System.Diagnostics.StackTrace/tests/StackTraceSymbolsTests.cs (+35/-2): CoreCLR・Mono双方を対象としたブラウザ回帰テストを追加。正確なソースファイル名・行番号、繰り返し検索、VFS上にPDBが存在しないことを検証。既存のファイルロックテストも調整。
  • src/libraries/System.Diagnostics.StackTrace/tests/System.Diagnostics.StackTrace.Tests.csproj (+1/-1): テストプロジェクトから明示的なPDBのVFSステージングを削除。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）。PDBはスタックトレースでファイル情報が要求された際に遅延的に検索・キャッシュされます。

関連Issue

なし

その他

検証状況:

  • build.cmd clr+libs -os browser -a wasm -c Debug: 成功（警告・エラーなし）
  • CoreCLR browser-WASMテスト（NodeJS上で実行、ブラウザUIではない）: 136件成功・5件スキップ。WasmEnableWebcil=false でも同結果（テスト条件拡張前）。
  • 新規回帰テストは、外部PDBプローブを無効化すると失敗し、修正後は成功することを確認。
  • build.cmd mono+libs -os browser -a wasm -c Debug は python が PATH に存在せず genmintops.py 実行時に失敗（終了コード9009）。Monoでのテスト実行は未検証。

#135494 [cDAC][wasm] Keep caller SP for non-R2R callers and restore SoftwareExceptionFrame FP

  • 作成者: @lewing
  • 作成日時: 2026年10月09日 14:04:04(UTC)
  • マージ日時: 2026年10月20日 16:14:03(UTC)
  • ラベル: area-Diagnostics-cdac

概要

wasm向けcDAC（R2Rスタックウォーカー）のアンワインダを、ネイティブの WasmUnwindStackFrameCore / UpdateRegDisplay_Impl の挙動に揃える修正です。主な変更は次の3点です。

  • 非R2Rの呼び出し元: SPをクリアせず、IPとFPを null にしたうえで呼び出し元のSPを保持するようにしました。従来は、自身のフレーム内にアクティブな InlinedCallFrame を持つR2Rメソッドが、ウォーカーがそのフレームを越えられないため繰り返し報告されていました。
  • SoftwareExceptionFrame: IP・SPに加えてFPも復元するようにしました。FP（InterpreterFP）はwasmで唯一のcallee-savedレジスタですが、wasmでは CalleeSavedRegisters ディスクリプタが空のため、FPが前フレームの値のまま残っていました。
  • 非アクティブな InlinedCallFrame: ネイティブと同様に、インタプリタフレームのスタッシュへ書き込む前に return するようにしました。

変更内容

  • docs/design/datacontracts/StackWalk.md: 上記の挙動に合わせてドキュメントを更新（+24/-2）
  • .../StackWalk/Context/Wasm/WasmUnwinder.cs: 非R2R呼び出し元でSPを保持する処理に変更（+7/-10）
  • .../StackWalk/Context/WasmContext.cs: コンテキスト関連の小変更（+4/-3）
  • .../StackWalk/FrameHandling/WasmFrameHandler.cs: SoftwareExceptionFrame のFP復元と、非アクティブな InlinedCallFrame での早期 return を追加（+19/-1）
  • src/native/managed/cdac/tests/UnitTests/StackWalkTests.cs: スタックウォークのテストを追加（+165/-0）
  • src/native/managed/cdac/tests/UnitTests/WasmUnwinderTests.cs: アンワインダのテストを追加（+30/-0）

なお、以前の reverse P/Invoke チェックは、#135440 でタグ付きフレームのIDからそれらのルートを識別できると判明したため削除されています。

パフォーマンスへの影響

影響なし

関連Issue

  • #135440（reverse P/Invoke のルート識別に関する言及）
  • #135147（今回の対象外：ファンクレット内からウォークを開始した場合のリーフFP）
  • #134608（#135147 が依存）

その他

今回のPRに含まれないもの：

  • wasmでの IStackWalk.GetRuntimeFramePointer（ネイティブの GetRegdisplayStackMark に TARGET_WASM 実装がなく、揃える対象がないため）
  • ファンクレット内からウォークを開始した場合のリーフFP対応（#135147、#134608 に依存）

#135146 [wasm] [JIT] Contain Array Data Offsets

概要

WebAssembly (Wasm) 向けJITにおいて、配列要素アクセスのアドレス計算を並べ替え、配列データオフセットをload/storeのメモリオペランドに畳み込めるようにする変更です（#134465 を解決）。既存のcontainment（包含）ロジックの制約（アドレスが TYP_REF または TYP_BYREF であること）の範囲内で動作します。作成者によれば、同様の並べ替えはRISC-Vでは既に行われています。

変更内容

  • src/coreclr/jit/morph.cpp（+3/-0）
    • Wasm向けに、非構造体の配列でGC型の配列参照に限り、アドレスを (array + scaledIndex) + dataOffset の形に再構成する処理を追加。

パフォーマンスへの影響

実行時の速度やメモリに関する具体的な数値の記載はありません。作成者はコード生成の差分（Diffs）へのリンクを提示していますが、その内容は提供情報からは確認できません。Copilotのレビュー概要では、Wasmのコードサイズ改善という主張に対する直接的な検証がPR内に不足していると指摘されています。

関連Issue

#134465

その他

  • 影響範囲はJITのmorph段階のWasm向けコード生成（内部実装）で、公開APIや互換性への影響に関する記載はありません。
  • Copilotレビューの指摘事項（Findings）はなしで、変換自体は妥当と評価されています。

#135067 Enable ILLink caching and post-build purging in CI

概要

CIのLinux x64 / Windows x64 / macOS arm64 の CoreLib/libraries ジョブで、実験的な ILLink タスクキャッシュを有効化します。Azure Pipelines からジョブ専用のキャッシュを復元し、プラットフォームと構成ごとにスナップショットを分離します。ビルドとポストビルドの完了後、今回のビルドで使われなかったエントリを削除（purge）してから次のスナップショットを保存します。

作成者の報告によると、CIビルド 1642482 でのリンカーキャッシュのヒット数は次のとおりです。

  • Linux / macOS: 254/255（99.6%）
  • Windows: 252/255（98.8%）

3プラットフォームすべてで、復元・再利用・purge・スナップショット保存が成功したとのことです。

変更内容

  • eng/pipelines/coreclr/templates/setup-illink-cache.yml（新規）: ILLinkキャッシュのスナップショット復元とキャッシュ有効化の設定
  • eng/pipelines/coreclr/templates/purge-illink-cache.yml（新規）: ポストビルドで未使用エントリを削除するメンテナンス手順（致命的エラーにしない運用）
  • eng/pipelines/coreclr/templates/setup-build-caches.yml: キャッシュ設定側にILLinkキャッシュ設定を組み込み
  • eng/pipelines/common/global-build-job.yml: ポストビルドステップの後に purge を実行するよう追加
  • eng/pipelines/global-build.yml: 対応する設定の追加
  • docs/tools/illink/illink-tasks.md: 設定とCIでのメンテナンスに関するドキュメント更新
  • docs/design/tools/illink/task-cache.md: 設計ドキュメントの微修正

なお、PR全体（Copilotの概要より）では、ILLinkタスクのキャッシュ実装（ILLinkCache.cs など）、purge用ツール（ILLink.CacheTool）、関連テストの追加も含まれています。ただし本要約で挙げた変更ファイルはCI/ドキュメント関連のみです。

パフォーマンスへの影響

ILLinkの実行結果をキャッシュ再利用することでCIのビルド時間短縮が期待されます。上記ビルドでは98.8〜99.6%のキャッシュヒット率が報告されています。ただし、CIの実行時間の具体的な短縮値は提供情報に含まれていません。Copilotのレビューでは、CI上での実際の効果について人間による検証が必要と指摘されています。

関連Issue

なし

その他

  • 機能は「実験的（experimental）」と位置付けられています。
  • Copilotレビューの指摘（キャッシュキーへのビルド構成の包含、NUGET_PACKAGES の設定、purge失敗がキャッシュ保存を妨げる問題）は、最終的にすべて解決済みと記載されています。
  • Copilotは、ビルド・パイプラインテストは未実行であり、プラットフォーム間のキャッシュ復元・purge実行・ポストジョブでのスナップショット保存についてCI上での確認が必要としています。

#135066 Support ILLink caching in runtime library builds

概要

ランタイムのライブラリビルド（共有フレームワーク、out-of-band、ライブラリ単位のトリミング）で実行される ILLink を、実験的な ILLink キャッシュの対象にする変更です。キャッシュは引き続きオプトインです。既存のタスクパラメータを可能な限り再利用し、リンク属性・置換・アセンブリ検索ディレクトリに必要な範囲の追加引数形式のみをサポートします。アセンブリ解決や独自引数の優先順位は変更せずに、これらの入力をフィンガープリント化します。

変更内容

  • src/tools/illink/src/ILLink.Tasks/LinkTask.cs: サポート対象の引数を解析し、XML ファイル、アセンブリ候補、サイドカーなどの入力をハッシュ化してフィンガープリントに含める処理を追加。
  • eng/illink.targets: ライブラリ単位のトリミングをキャッシュ対象にし、オプションを既存のタスクパラメータへ移行。
  • src/libraries/oob-trim.proj: 警告抑制をタスクパラメータに変更。
  • src/libraries/sfx-finish.proj: シンボル保持（symbol retention）をタスクパラメータで指定するよう変更。
  • src/tools/illink/test/ILLink.Tasks.Tests/ILLink.Tasks.Tests.cs: 入力変更時のキャッシュ無効化とキャッシュバイパスのテストを追加。
  • docs/design/tools/illink/task-cache.md, docs/tools/illink/illink-tasks.md: フィンガープリントとバイパスのルール、サポートされるキャッシュ入力に関するドキュメントを更新。

パフォーマンスへの影響

Linux x64 のプロトタイプ計測では、キャッシュヒット時の ILLink タスク時間が以下のように短縮されました。

  • CoreLib: 4,103 ms → 80 ms
  • System.Collections: 1,036 ms → 63 ms

これはタスク単位の計測であり、ビルド全体の高速化ではありません。

関連Issue

なし

その他

  • Copilot のレビューでは、以下の 2 点が中程度の指摘として挙げられ、「変更推奨」と判定されています。
    • カスタム引数が、先に強制された未解決参照のスキップ設定を上書きしてしまう。
    • カスタム引数が、末尾のシンボル書き換え設定を上書きしてしまう。
    • いずれもキャッシュ無効時でも動作が変わり得る点が懸念されています。
  • ビルドとテストは実行されていないと記載されています。
  • 作成者によると、この内容は AI の支援を受けて作成されています。

#134910 [JIT] Rationalize: Re-run pre-order processing on identity shuffle rewrite in PreOrderVisit

概要

JITのRationalizeフェーズにおいて、PreOrderVisit中のRewrite*Intrinsicで別ノードに置き換えられた場合、その置換後ノードに対して前処理（pre-order processing）が実行されない問題を修正します（#133787 の解決）。

問題となるIRは、外側のShuffleが恒等シャッフルであり、RewriteHwIntrinsicAsUserCallで畳み込まれて消える一方、置換ノードとなる内側のShiftRightLogical128BitLane（引数が非定数のためGT_CALLへの書き戻しが必要）が処理されないケースです。修正により、Rewrite*Intrinsicが異なるノードを返した場合、その新しいノードに対して処理ロジックを再実行します。

変更内容

  • src/coreclr/jit/rationalize.cpp: 置換されたノードに対してpre-order処理を再実行するよう変更（+43/-2）
  • src/coreclr/jit/rationalize.h: 変更あり（+28/-28）。内容の詳細は提供情報からは不明
  • src/tests/JIT/Regression_ro_2/Runtime_133787.cs: 回帰テストを追加（+51/-0）

Copilotのレビュー概要によると、ノードが変化しなくなるまでintrinsicの書き換えを繰り返し、ネストされた遅延ハードウェアintrinsicがユーザー呼び出しに変換されるようにしています。

パフォーマンスへの影響

影響なし（提供情報にパフォーマンスに関する記載なし）

関連Issue

#133787

その他

  • Copilotのレビューでは、Checked-buildで報告された回帰の再発防止のため、非定数のVector128.Shuffle即値に対する的を絞ったテストの追加が推奨されています（Medium severity、指摘1件）。
  • 本PRではRuntime_133787.csが追加されていますが、このレビュー指摘への対応状況は提供情報からは確認できません。

#134819 Update x64 Helix test VMs to Azure Linux 4

  • 作成者: @richlander
  • 作成日時: 2026年09月28日 21:32:24(UTC)
  • マージ日時: 2026年10月20日 21:52:51(UTC)
  • ラベル: area-Infrastructure

概要

runtime が所有する x64 Helix のコンテナホストを Azure Linux 3 から Azure Linux 4 (AzureLinux.4.Amd64[.Open]) に移行するPRです。スタンドアロンの Helix テスト VM は引き続き Azure Linux 3 (AzureLinux.3.Amd64[.Open]) のままです。

  • Azure Linux 4 はコンテナのホスト専用で使用します。Azure Linux 4 のパッケージリポジトリに現時点で libmsquic が存在しないため、ベアのテスト VM としては選択していません（Azure Linux 4 用 Helix prerequisite コンテナが、Azure Linux 3 の ms-oss フィードから libmsquic をインストールして対処）。
  • Azure Linux 3 / 4 の明示的なコンテナテストのカバレッジは維持され、変わるのは基盤となる Helix ホストのみです。
  • Azure Pipelines のビルドエージェントは、ビルドプールに Azure Linux 4 イメージがないため build.azurelinux.3.amd64[.open] のままです。
  • コンテナのタグやダイジェストは変更されておらず、MCR イメージの可用性への影響はありません。

変更内容

Helix キュー設定の YAML 4ファイルを更新しています（計 +30/-30）。

  • eng/pipelines/coreclr/templates/helix-queues-setup.yml (+4/-4)
  • eng/pipelines/helix-platforms.yml (+12/-12)
  • eng/pipelines/installer/helix-queues-setup.yml (+1/-1)
  • eng/pipelines/libraries/helix-queues-setup.yml (+13/-13)

パフォーマンスへの影響

影響なし（CI インフラの設定変更のみ）。

関連Issue

なし

その他

  • 作成者による検証:
    • git diff --check 通過
    • 変更した4つの YAML を Ruby の YAML.load_file でパースして成功
    • スタンドアロンの AzureLinux.4.Amd64[.Open] キュー値が残っていないことを確認
    • 残存する Azure Linux 4 参照がすべてコンテナホストの複合マッピングであることを確認
    • build.azurelinux.4.amd64 参照が残っていないことを確認
  • カバレッジ: デフォルトの runtime パイプラインが主要なコンテナホストのマッピングを、runtime-extra-platforms が Fedora、Debian、openSUSE、Alpine edge を支えるホストの変更をカバーします。
  • Azure Linux はこれらのリリースについて固定のサポート終了日を公開していません。

#133533 Convert .data tls IL tests to C++/CLI

概要

.data tls を使用していた4つのILテストを、C++/CLI（IJW）ベースのテストへ変換するPRです。これらのテストは実際にはC++/CLIのシナリオを検証するものであり、そのシナリオはC++/CLI経由でのみサポートされているため、変換が行われました。ネイティブ側はC++/CLIで実装し、マネージド側のラッパーが UnsafeAccessor / UnsafeAccessorType を使ってネイティブの静的エントリポイントを呼び出します（リフレクションは不使用）。

変換対象:

  • JIT/Directed/tls/Test-TLS
  • JIT/Directed/tls/MutualRecurThd-TLS
  • JIT/Regression/CLR-x86-JIT/V1.2-M01/b03689
  • JIT/Regression/CLR-x86-EJIT/v1-m10/b07847

ネイティブ側のTLSは、ファイルスコープの __declspec(thread) グローバル変数で実装され、#pragma unmanaged/#pragma managed の配置が使われます。

変更内容

  • ビルド基盤
    • src/tests/Interop/Directory.Build.targets にあった、IJW向けネイティブランタイム依存（Debug CRT/UCRT）のコピー処理を src/tests/Directory.Build.targets へ移動し、Interop ツリー外でも再利用可能にしました。
    • Interop 専用の TestLibraryProjectPath の上書きは Interop/Directory.Build.props に残しています。
    • eng/native/ijw/IJW.cmake に13行追加されています（変更内容の詳細は提供情報からは不明）。
  • 新規追加（各テスト）
    • ネイティブC++/CLI実装（.cpp）とその CMakeLists.txt
    • マネージドラッパー（.cs / .csproj）
    • JIT/Directed/tls 配下は cppcli/（TestTLSNative.cpp）と cppcli-mutual/（MutualRecurThd-TLS.cpp）のサブディレクトリを追加し、tls/CMakeLists.txt から参照しています。
  • 削除
    • 元の .il ファイル（MutualRecurThd-TLS.il は約3,300行）と .ilproj
  • 参照更新
    • Directed_ro.csproj のマージテスト参照を .ilproj から .csproj に変更しました。

パフォーマンスへの影響

影響なし（テストコードの変換であり、ランタイム/ライブラリ本体への変更はありません）。

関連Issue

  • #133538（Copilotのレビューコメント内で、ネイティブTLSの再現コードの出典として言及されています）

その他

  • 本PRはGitHub Copilotの支援を受けて作成されています。
  • Copilotのレビュー経過:
    • 初回: 4つの.csprojにIJW固有フラグが不足している点が指摘され、その後解決済みとされています。
    • 2回目: TestTLSNative.cpp で #pragma unmanaged/managed の分離がPR説明と一致していない点が指摘されました。
    • 最新: 「Needs a closer look」で、直近の新規指摘は0件です。ただし以下は「Previously missed」として残っています。
      • 4つのネイティブ.cppに #pragma unmanaged/managed の境界がなく、IJWのTLSコードパスを確実に検証できない可能性があります。
      • 4つの.csprojに CrossGenTest=false の指定が必要です（既存のIJWテストは混在モードがcrossgen2と非互換のため無効化している）。
  • 古い指摘として、IJWテストをChecked buildでゲートすべきというものもありましたが、その解消状況は提供情報からは不明です。

#131428 Ensure that x64 disassembly names operands at the size actually encoded

概要

x64 JITの逆アセンブリ表示（emitDispIns とその補助関数）において、実際にエンコードされたバイト列と一致しないオペランドサイズが表示される問題を修正します。表示のみの変更であり、コード生成は変わりません。

  • movzx のデスティネーションが64bitと表示されていた
  • GC型のレジスタ自己ゼロ化 xor が64bitと表示されていた
  • v{extract,insert}{f,i}32x4 のimm8レーンセレクタが表示されなかった
  • movmskps/movmskpd のデスティネーションが64bit GPRと表示されていた
  • cvtsi2*/vcvtusi2*/vmovd のGPRオペランド名がベクトルサイズ基準になっていた
  • 縮小変換（narrowing convert）のメモリ形式でデスティネーションが元サイズで表示されていた
  • ブロードキャスト命令のソースがデスティネーション幅で表示されていた

修正例（同一バイト列でも表示が変わる）:

before                                  after
C4E27D78C0    vpbroadcastb ymm0, ymm0   vpbroadcastb ymm0, xmm0
62F2FD4819C0  vbroadcastsd zmm0, zmm0   vbroadcastsd zmm0, xmm0

変更内容

  • src/coreclr/jit/emitxarch.cpp（+159/-29）
    • emitDispConstant: INS_FLAGS_HasPseudoName による早期リターンの例外として、{vextract,vinsert}{f,i}32x4 ではimm8を表示
    • emitDispIns:
      • movzx を movsx と分離し、デスティネーションを32bit表示に（ARD/SRD/RRD/MRDの4箇所）。movsx は実際に REX.W が付くため従来どおり64bit
      • xor reg, reg が idOpSize(EA_4BYTE) に縮退された場合に合わせて表示を修正
      • movmskps/movmskpd を pmovmskb と同様に32bit GPR表示に
      • cvtsi2*/vcvtusi2*/vmovd のGPRオペランド名を GetInputSizeInBytes（Input_32Bit/Input_64Bit フラグ）から決定
      • ベクトルソースのブロードキャストでソースをxmm（下位要素）として表示
    • GetNarrowedDstAttr を新設し、レジスタ形式とARD/SRD/MRDのメモリ形式で共有（/2 13件、/4 3件の手動リスト）

パフォーマンスへの影響

影響なし。表示のみの変更で、コード生成は不変です。

  • System.Private.CoreLib の75,012メソッドを（ニーモニック, エンコード長）で比較し、差分は4件のみ。これはP/Invokeインラインフレーム呼び出しのヘルパーターゲットがASLRにより rel32 範囲内外に移動するためで、同一JITを2回実行した対照実験でも再現を確認済み

検証結果（CoreLibのバイト精度PMIコーパス、1,134,687命令を確認、幅の不一致は0件）:

base this PR
64bit dstの movzx 19,815 0
64bit表示の自己ゼロ化 xor 13,256 0
64bit dstの v?movmskp[sd] 211 0
ymm<-ymm/zmm<-zmm 表示のブロードキャスト 89 0
セレクタ表示ありの vextract/vinsert*32x4 0 52

関連Issue

なし

その他

  • 既知の未対応事項: JitDump 時に emitDispIG から呼ばれる emitDispIns は、xor の縮小がまだ行われていない出力前の段階で呼ばれるため、そのパスでは従来の広い名前が表示されます。EA_SIZE(EA_GCREF) == idOpSize() となり新条件が単に偽になるだけで、誤表示にはなりません
  • GetNarrowedDstAttr はメタデータのみでは縮小変換を判別できない（cvtpd2ps と vaddps が同じ比率になる）ため、手動メンテナンスのリストです。静的監査では漏れ・不要エントリはなしとのことです
  • CoreLibはブロードキャストのレジスタ形式を出力しないため、ターゲットを絞ったリプロで8命令の修正を確認しています
  • 作者によればGitHub Copilotを用いて作成されています

#129510 [release/10.0] Fix MemoryCache negative _cacheSize drift that permanently latches a size-limited cache

概要

MemoryCache（SizeLimit 設定時）で、内部のサイズカウンター _cacheSize が並行処理下で負の値にドリフトし、キャッシュが永続的に使用不能になる不具合の修正を release/10.0 にバックポートするPRです（元PR: #129215）。

報告されている影響: SizeLimit を設定した環境で _cacheSize が負の状態になると、以降のすべての Set が例外やログなしに黙って破棄され、自己回復せず再起動まで復旧しません。通常の並行負荷下で複数クラスターにて一貫して発生しているとのことです。この問題は .NET 9 の #103931 によるリグレッションです。

変更内容

  • src/libraries/Microsoft.Extensions.Caching.Memory/src/MemoryCache.cs (+30/-12): サイズ会計（_cacheSize の加減算）処理の修正
  • src/libraries/Microsoft.Extensions.Caching.Memory/tests/MemoryCacheConcurrentSizeTrackingTests.cs (+121/-0): 並行時のサイズ追跡を検証するテスト（ストレステストを含む）を新規追加

※ 修正の具体的な実装内容は、提供された情報（変更ファイルの行数のみ）からは判断できません。

パフォーマンスへの影響

影響なし（記載された情報の範囲では、パフォーマンスに関する言及やベンチマーク結果はありません）。

関連Issue

  • 元PR: #129215（バックポート元）
  • リグレッション原因: #103931（.NET 9 で導入）

その他

  • リスク評価は Medium: 並行処理に敏感なサイズ会計コードの変更であるため、ストレステストが追加されています。
  • 顧客報告による修正であり、レプリケーションロジックの駆動にキャッシュを使用している環境で深刻な影響が出ていました。
目次