Pull Request on 2026年10月13日

Unix上でデフォルトのservicingディレクトリのルートが /opt/servicing ではなく opt/servicing（先頭スラッシュなしの相対パス）として組み立てられていた問題を修正します。あわせて、必要なアクセス権限を持たないservicingディレクトリは拒否されるようになります。

変更内容

src/native/corehost/hostmisc/pal.unix.cpp: デフォルトのservicingディレクトリのパス構築を修正（+10/-10）
src/native/corehost/hostpolicy/args.h: servicingディレクトリに必要なアクセス権限がない場合に拒否する処理を追加（+3/-1）

パフォーマンスへの影響

影響なし

その他

Unix環境のネイティブホスト（corehost）に限定された修正で、公開APIの変更ではありません。
提供された情報には、互換性への影響、セキュリティ上の重要度やCVE番号、ベンチマーク結果に関する記載はありません。

#135692 JIT: Preserve Half estimate ISA dependencies in ReadyToRun

作成者: @tannergooding
作成日時: 2026年10月13日 18:19:55(UTC)
マージ日時: 2026年10月13日 22:14:08(UTC)
ラベル: area-CodeGen-coreclr

概要

Half.ReciprocalEstimate と Half.ReciprocalSqrtEstimate をハードウェアイントリンシックとしてインポートする際に、負のISA前提条件（negative ISA prerequisites）を保持するようにJITを修正しています。これにより、ReadyToRun（R2R）では既存の非決定的イントリンシックのポリシーに従って、estimate系に依存するコードをガードできるようになります。精密な Half.Sqrt には影響しません。

変更内容

src/coreclr/jit/importercalls.cpp（+4/-2）: Half の estimate 系メソッドをハードウェアイントリンシックとしてインポートする際に、ISA依存関係が保持されるよう修正
src/tests/JIT/Regression_o_1/Runtime_101731.cs（+11/-0）: 非ReadyToRun時の Half estimate の挙動に対する回帰テストを追加
src/tests/readytorun/HardwareIntrinsics/X86/HalfEstimateR2R.cs（+78/-0）: ReadyToRun の ISA fixup を検証する新規テストを追加
src/tests/readytorun/HardwareIntrinsics/X86/HalfEstimateR2R.csproj（+14/-0）: 上記テスト用のプロジェクトファイルを追加

パフォーマンスへの影響

影響なし（パフォーマンスに関する記載・ベンチマーク結果は提供された情報に含まれていません）。

その他

作成者による検証結果：
- jitformat.py（windows/x64）: 成功
- build.cmd clr.jit -rc checked および build.cmd clr.tools -rc checked: 成功
- HalfEstimateR2R.csproj と Regression_o_1.csproj を対象としたテストビルド: 成功
- HalfEstimateR2R.cmd: 成功。非ReadyToRunの TestHalfEstimates は 1 passed, 0 failed
本PRの説明はGitHub Copilotにより生成された旨が記載されています。

#135686 Emit a zero-offset local address as a mov

作成者: @tannergooding
作成日時: 2026年10月13日 17:43:13(UTC)
マージ日時: 2026年10月13日 22:37:17(UTC)
ラベル: area-CodeGen-coreclr

概要

x64 JITにおいて、ローカル変数のフレームオフセットがゼロに解決された場合、lea reg, [base] の代わりに mov を生成するよう変更します。フレームレイアウト確定後にチェックを行い、元の emitAttr を維持します。インデックス付きの場合や動的なスタック相対アドレッシングの場合は対象外です。

変更内容

src/coreclr/jit/emitxarch.cpp (+51/-0): ゼロオフセットのローカルアドレスを mov として出力する処理を追加
src/coreclr/jit/emitxarch.h (+1/-0): 上記に関連する宣言を追加

パフォーマンスへの影響

コードサイズの改善が報告されています。

元のコーパス/ベースでのPMI計測: 865メソッドで正味942バイト削減
7メソッドでループアラインメントの影響によりコードサイズが増加
この計測は現行の dotnet/main へのリベース前のもので、再計測はされていません
実行速度やスループットに関する数値は記載されていません

その他

リベース後のブランチでの検証結果：

build.cmd clr+libs -rc Checked -lc Release: 成功（警告・エラーなし）
JITテスト（x64 checked）: 3,466件成功、0件失敗、107件スキップ（計3,573件）
build.cmd clr.jit -c Release: 成功（警告・エラーなし）
jitformat.py によるフォーマットチェック: 変更なし

PR説明はGitHub Copilotにより生成されたものです。

#135685 Remove the redundant jump in the HW intrinsic jump table fallback

作成者: @tannergooding
作成日時: 2026年10月13日 17:42:44(UTC)
マージ日時: 2026年10月13日 22:13:48(UTC)
ラベル: area-CodeGen-coreclr

概要

x64向けハードウェアイントリンシックのジャンプテーブル・フォールバックにおいて、最後のケースの後に出力されていた無条件ジャンプを省略する最適化です。最後のケースがそのままスイッチ終端へフォールスルーするため、動作を変えずにコードサイズが小さくなります。それ以前のケースは引き続きスイッチ終端へのジャンプを保持します。

変更内容

src/coreclr/jit/hwintrinsiccodegenxarch.cpp (+12/-1)
- 各ケース終端のジャンプの出力を次のイテレーションまで遅延させ、最後に出力されるケースでは冗長なジャンプを出力しないようにしました。

パフォーマンスへの影響

実行速度やスループットへの影響についての記載はありません。
元のコーパス/ベースでの PMI 計測では、438メソッドで合計1,302バイトのコードサイズ削減が確認されています。
ただしこの計測は現在の dotnet/main へのリベース前のものであり、更新されていません。

その他

影響範囲は JIT（x64 のハードウェアイントリンシックのコード生成）の内部実装であり、公開APIや互換性への影響についての記載はありません。
リベース後のブランチでの検証結果:
- build.cmd clr+libs -rc Checked -lc Release: 成功（警告・エラーなし）
- src\tests\build.cmd x64 checked -tree JIT: 成功
- src\tests\run.cmd x64 checked -tree JIT: 成功（3,466件成功、0件失敗、107件スキップ、計3,573件）
- build.cmd clr.jit -c Release: 成功（警告・エラーなし）
- jitformat.py: 成功（フォーマット変更なし）
Copilotによるレビュー概要では、制御フローが保たれており JIT の検証も適切であるとして、承認推奨（未解決の指摘事項は0件）とされています。

#135677 Disable Runtime_133581 on Mono

作成者: @jkotas
作成日時: 2026年10月13日 15:25:09(UTC)
マージ日時: 2026年10月13日 17:41:58(UTC)
ラベル: area-Infrastructure-mono

概要

Mono上でSIGSEGV（セグメンテーション違反）が発生するため、回帰テスト Runtime_133581 をMonoでは無効化するPRです。同様の症状で失敗するテストが複数あるとのことです。ランタイム/コンパイラ/ライブラリ本体の実装変更ではなく、テストの実行条件のみを変更するもので、公開APIへの影響はありません。

変更内容

src/tests/JIT/Regression_ro_2/Runtime_133581.cs（+1/-0）: Monoでの実行を無効化するための1行を追加（具体的な記述内容は提供情報からは不明）

パフォーマンスへの影響

影響なし

その他

作成者の記載によると、本PRはAI/Copilotによって生成されたものです。
互換性（破壊的変更・非推奨化）に関する変更はありません。

#135668 Correct decimal conversions to Half and BFloat16

作成者: @tannergooding
作成日時: 2026年10月13日 09:23:37(UTC)
マージ日時: 2026年10月13日 22:31:42(UTC)
ラベル: area-System.Numerics

概要

decimal から Half / BFloat16 への変換で、ターゲット形式の中間点（midpoint）のわずかに片側にある値が、一度 double に丸められると中間点そのものになり、誤った隣接値に丸められる問題を修正します。有効な場合はターゲット形式向けのファストパスを使い、それ以外の値には厳密なターゲット精度でのフォールバックを用います。あわせて Half の MinExponentRoundToEven の境界値を -21 から -22 に修正しており、これにより影響を受けていた Half のパース時のタイ（tie）処理も修正されます。

変更内容

src/libraries/System.Private.CoreLib/src/System/Decimal.DecCalc.cs（+89/-25）: decimal から 16bit 浮動小数点形式への変換ロジックを追加・修正（ファストパス＋厳密フォールバック）
src/libraries/System.Private.CoreLib/src/System/Decimal.cs（+4/-0）: 変換処理の呼び出し側の変更
src/libraries/System.Private.CoreLib/src/System/Half.cs（+2/-5）: MinExponentRoundToEven を -21 → -22 に修正
src/libraries/System.Private.CoreLib/src/System/Numerics/BFloat16.cs（+1/-3）: BFloat16 側の変換経路の修正
HalfTests.cs（+14/-3）、BFloat16Tests.cs（+5/-0）: 中間点付近の値、タイ、サブノーマルのケースに対する回帰テストを追加

パフォーマンスへの影響

ローカルでの BFloat16 の簡易比較（123.456m）では、decimal キャストが 6.368 ns、(BFloat16)(double)value が 4.096 ns でした。
計測値のばらつきが大きく、別途ベースラインのランタイムをビルドして比較したものでもないため、回帰を断定する結果ではなく、評価すべき観測コストとして扱うよう作成者が注記しています。

その他

挙動の変更範囲は、decimal から 16bit 形式への変換と、修正された tie 境界での Half のパースに限定されると作成者は述べています。
テスト結果（作成者報告）: clr.corelib+clr.nativecorelib+libs.pretest のビルドは警告・エラーなしで成功、System.Runtime.Tests は 78,595 件が成功（失敗 0、スキップ 87）、git diff --check も通過しています。
作成者によると、本PRの説明は GitHub Copilot を用いて作成されています。

#135666 Enable normal-completion finally emission for NativeAOT Wasm

作成者: @MichalStrehovsky
作成日時: 2026年10月13日 08:51:18(UTC)
マージ日時: 2026年10月13日 23:28:37(UTC)
ラベル: arch-wasm area-NativeAOT-coreclr

概要

NativeAOT の Wasm ターゲットで、例外を投げずに finally を正常完了させる経路を有効化する変更です。JIT の EH 句から funclet を分類し、その結果（finally/fault の区別と句の順序）を NativeAOT と ReadyToRun の両メソッドノードに保持します。これにより、シリアライズ済み EH レコードをデコードする必要がなくなります。

また「親メソッド + funclet 序数」による参照を、名前付き funclet シンボルへの再配置（relocation）に変換します。これによりリンカーがテーブルスロットを独立して割り当てられます。EH 情報と依存関係は維持されます。

作成者による再現手順では、通常／ジェネリックの関数ポインタ、ジェネリック辞書ルックアップ、finally を通る正常完了を試し、Hi が2行出力され終了コード 0 になることが期待結果です。

try
{
    Call(&Print);
}
finally
{
    Call(&PrintGeneric<string>);
}

変更内容

CorInfoImpl.cs: JIT の EH 句から Wasm の funclet 種別を分類・公開（+30）
MethodCodeNode.cs: NativeAOT 側で funclet 種別の配列を保持（+8/-2）
MethodWithGCInfo.cs: ReadyToRun 側で funclet 種別を直接保持し、旧処理を削減（+6/-38）
WasmRelocatableObjectWriter.cs: 親メソッド + funclet 序数の参照を名前付き funclet シンボルへの再配置に書き換え（+11/-1）
WasmObjectWriter.cs: funclet のシンボル命名を一元化し、パラメータのコメントを更新（+6/-3）

パフォーマンスへの影響

影響なし（ベンチマーク記載なし）

その他

対象はコンパイラ／ツール側（ILC・crossgen2・Wasm オブジェクトライター）で、公開 API の変更ではありません。
管理例外のスローおよび例外的アンワインドはスコープ外です。再現は最小の system module を使い、CoreLib や完全なランタイムは使用しません。
Copilot のレビューでは、この relocatable-object の finally 処理に対する自動回帰テストがない点が中程度の指摘として挙がっています。

#135662 [manual] Merge release/9.0-staging into release/9.0

作成者: @ViveliDuCh
作成日時: 2026年10月13日 06:07:18(UTC)
マージ日時: 2026年10月13日 11:35:29(UTC)
ラベル: NO-SQUASH Servicing-approved area-System.Security

概要

release/9.0-staging ブランチを release/9.0 にマージする手動マージPRです。作成者・Copilotによる概要の記載はなく、詳細な意図は提供情報からは不明です。変更ファイルから、依存関係バージョンの更新、パイプライン設定、CoreCLRのamd64アセンブリ、暗号化関連のSafeHandle、テストの変更が含まれていることが確認できます。

変更内容

依存関係/バージョン管理
- eng/Version.Details.xml（+30/-30）、eng/Versions.props（+15/-15）: 依存パッケージのバージョン更新と思われる変更
ビルド/パイプライン
- eng/pipelines/official/jobs/prepare-signed-artifacts.yml（+4/-0）: 署名済みアーティファクト準備ジョブへの追記
CoreCLR（amd64）
- src/coreclr/vm/amd64/Context.S（+8/-8）
- src/coreclr/vm/amd64/virtualcallstubamd64.S（+9/-9）
System.IO.FileSystem.Watcher
- FileSystemWatcher.Linux.cs（+1/-1）: Linux実装の軽微な修正
System.Security.Cryptography
- NCryptSafeHandles.cs（+22/-11）: NCrypt関連SafeHandleの変更
- テスト: CngKeyTests.cs（+60/-0）、PublicKeyTests.cs（+1/-0）、共通テスト RSA/SignVerify.cs（+2/-0）
System.Diagnostics.Process
- tests/ProcessWaitingTests.cs（+12/-8）: テストの修正

パフォーマンスへの影響

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

その他

ステージングブランチからリリースブランチへの手動マージであり、複数の変更を一括で取り込むものです。個々の変更の詳細な意図や互換性への影響は、提供情報からは判断できません。
CoreCLRのamd64アセンブリ（.S）変更とNCrypt SafeHandle変更はランタイム/ライブラリの内部実装に属しますが、具体的な挙動変更の内容は不明です。

#135661 [manual] Merge release/8.0-staging into release/8.0

作成者: @ViveliDuCh
作成日時: 2026年10月13日 05:18:05(UTC)
マージ日時: 2026年10月13日 11:32:35(UTC)
ラベル: NO-SQUASH Servicing-approved area-codeflow

概要

release/8.0-staging ブランチを release/8.0 へ手動でマージするPull Requestです。作成者・Copilotによる概要の記載はなく、変更ファイル一覧から確認できる範囲で、依存関係・ビルド基盤の更新、CoreCLRのVM（仮想スタブ）修正、Cryptography関連の修正とテスト追加、パイプライン定義の変更が含まれていることが分かります。

変更内容

依存関係・SDK更新
- eng/Version.Details.xml、eng/Versions.props、global.json、.config/dotnet-tools.json を更新
共通ビルド基盤（eng/common）
- templates / templates-official 配下の job.yml、onelocbuild.yml、send-to-helix.yml を更新
CIパイプライン
- eng/pipelines/official/jobs/prepare-signed-artifacts.yml（+4）
- eng/pipelines/runtime-extra-platforms.yml（-42）
- eng/pipelines/runtime.yml（+4/-23）
CoreCLR VM
- src/coreclr/vm/amd64/virtualcallstubamd64.S（+9/-9）
System.Security.Cryptography
- NCryptSafeHandles.cs（+22/-11）を修正
- CngKeyTests.cs（+60）にテストを追加
- SignVerify.cs、PublicKeyTests.cs、CoseTestHelpers.cs のテストを調整
System.Diagnostics.Process テスト
- ProcessStartInfoTests.Windows.cs（+13/-27）を変更

パフォーマンスへの影響

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

その他

本PRは複数の変更を含むブランチ間マージであり、個々の変更の意図・互換性への影響（公開APIの変更や破壊的変更の有無など）は提供された情報からは確認できません。
変更の多くはビルド基盤・依存関係の更新で、ランタイム本体への変更は主に virtualcallstubamd64.S（AMD64用の仮想スタブ）と NCryptSafeHandles.cs（Cryptography）です。

#135644 Read metadata stream count as unsigned in MetadataReader

作成者: @Empiree
作成日時: 2026年10月12日 20:57:50(UTC)
マージ日時: 2026年10月13日 18:47:32(UTC)
ラベル: area-System.Reflection.Metadata community-contribution

概要

MetadataReader がメタデータルートからストリーム数を読み取る際、ReadInt16（符号付き）を使用していたため、0x8000 以上のカウントが負の値になり、配列確保時に OverflowException がスローされる問題を修正します。ECMA-335 (II.24.2.1) ではストリーム数は2バイトの符号なし値であり、CoreCLR のネイティブリーダーも USHORT として読み込んでいます。修正により ReadUInt16 を使用するようになり、不正なヘッダーに対してはコンストラクターのドキュメントどおり BadImageFormatException が発生します。

変更内容

src/libraries/System.Reflection.Metadata/src/System/Reflection/Metadata/MetadataReader.cs (+1/-1)
- ストリーム数の読み取りを ReadInt16 から ReadUInt16 に変更
src/libraries/System.Reflection.Metadata/tests/Metadata/MetadataReaderTests.cs (+22/-1)
- 同様にストリームヘッダーを解析しているテスト用ヘルパー ObfuscateWithExtraData も ReadUInt16 に変更
- ストリーム数 0x8000 と 0xFFFF で BadImageFormatException が発生することを検証する新規テストを追加（修正前は OverflowException で失敗）

パフォーマンスへの影響

影響なし

その他

作成者による検証として、CoreLib のメタデータに空のストリームヘッダーを追加してカウントを 0x8000 / 0xFFFF にしたケースでも、修正後は元のメタデータと同様に読み取れることを確認しています（修正前は OverflowException）。
ライブラリ内の他の ReadInt16 呼び出しは問題ないと作成者は判断しています。CoffHeader 関連は公開APIの short 型と一致しており、負の NumberOfSections は PEHeaders で既に拒否されています。
作成者によると、本PRはAIアシスタントの支援を受けて作成されています。

#135643 [release/11.0] Give the nested process chain in ProcessWaitingTests depth-proportional wait budgets

作成者: @github-actions[bot]
作成日時: 2026年10月12日 20:53:19(UTC)
マージ日時: 2026年10月13日 15:27:38(UTC)
ラベル: Servicing-approved area-System.Diagnostics.Process

概要

release/11.0 向けのバックポートです（元PR: #135608）。ProcessWaitingTests のネストしたプロセスチェーンのテスト（WaitChain / WaitAsyncChain）で発生していたタイムアウトによる断続的なCI失敗に対し、待機時間（タイムアウト）の予算を、各待機がカバーするネストプロセス数に比例してスケールさせます。テストのみの変更で、製品コードやアサーションは変更されていません。

変更内容

src/libraries/System.Diagnostics.Process/tests/ProcessWaitingTests.cs（+12/-8）
- ネストしたプロセスチェーンを扱うテストで、各待機のタイムアウトをチェーンの深さ（ネストプロセス数）に比例した値にするよう調整

パフォーマンスへの影響

影響なし（テストコードのタイムアウト調整のみ）。

その他

顧客影響: 社内で発見された断続的なCIテスト失敗。製品の動作変更はなし。
リグレッション: なし（既存のテストタイムアウト問題）。
テスト: 元PR #135608 では、両チェーンテストがWindows x86、Linux x64、macOS arm64で成功したと報告されています。このバックポートでは追加のローカルテストは未実施で、CIは実行中であり、現時点で失敗が出ています。
リスク: 低（テスト専用のタイムアウト調整。アサーションと製品コードは不変）。

#135624 Kill process tree descendants before ancestors on Unix

作成者: @thomhurst
作成日時: 2026年10月12日 15:10:49(UTC)
マージ日時: 2026年10月13日 12:24:17(UTC)
ラベル: area-System.Diagnostics.Process community-contribution

概要

Unix 上の Process.Kill(entireProcessTree: true) が、macOS で意図しないプロセス（GitHub ホステッドランナーの Runner.Listener / Runner.Worker 等）に SIGHUP/SIGCONT/SIGTERM を発生させる問題（#131944）の修正です。

従来は、ツリー全体に SIGSTOP を送った後、深さ優先の先行順（親が先）で SIGKILL を送っていました。親が先に死ぬと、停止中の子が launchd に reparent されます。その子が終了する際、XNU の fixjobc() が pg_jobc をデクリメントしてプロセスグループが誤って orphaned と判定され、orphanpg() が停止中のメンバーを検出して同一プロセスグループ全体に SIGHUP と SIGCONT を送っていました。

修正では、収集済みのリストを逆順に走査し、子孫を祖先より先に SIGKILL します。SIGKILL は停止状態を即座に解除するため、祖先が終了して子が reparent される時点で停止中のプロセスが残りません。

変更内容

src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs（+9/-1）
- 停止済みプロセスへの kill を逆順（子孫 → 祖先）に変更
- macOS のプロセスグループに関する理由をコメントで記載

ツリー全体は kill 前にすべて収集されるため、KillOnParentExit（PR_SET_PDEATHSIG）のために導入された「停止→kill」の 2 段階方式の意図も損なわれません。

パフォーマンスへの影響

影響なし（記載なし）。

その他

残存リスク：
- 子が親より遅く終了した場合は reparent され、ツリーの一部がまだ停止している間に終了すると、シグナルが発生し得ます（レースは狭い）。
- 以前に reparent された無関係なプロセスが、KillTree による停止中に同一プロセスグループ内で終了した場合も、トリガーされ得ます。完全に回避するには macOS で SIGSTOP を使わない必要がありますが、それは SIGSTOP が防いでいる fork レースを再発させます。
旧来の単一パス KillTree（.NET 10）も同様の親先行順序のため影響を受けます。
新規テストは追加されていません。再現には launchd と同一セッションのプロセスグループが必要で、テストからは構築できず、Linux では orphaned グループが正しく計算されるためです。既存の kill-tree および KillOnParentExit テストが挙動をカバーします。
Copilot のレビューでは、カーネルの細かなプロセスグループ仕様に依存し、直接の回帰テストがない点が「要注意」とされています（未解決の指摘は 0 件）。

#135618 Replace badssl HTTP certificate tests with loopback servers

作成者: @rzikm
作成日時: 2026年10月12日 08:20:36(UTC)
マージ日時: 2026年10月13日 10:48:29(UTC)
ラベル: area-System.Net.Http

概要

HTTP証明書検証テストが外部の badssl.com に依存していたため、ループバックサーバーと既存テストヘルパーで生成した証明書に置き換えるPRです。外部の可用性や証明書設定に左右されなくなります。製品コードおよび公開APIの変更はありません（テストのみ）。

変更内容

期限切れ・自己署名・ホスト名不一致の証明書について、既定の検証、カスタムコールバック、検証無効化ハンドラーの各ケースをループバックサーバーで検証するよう変更。これらはインナーループで実行されるようになります。
SocketsHttpHandler の検証エラーを分離するため、スコープ付きの X509ChainPolicy カスタムトラストを使用。
既存のローカルPKI／失効レスポンダーを使い、信頼されたルートをインストールせずに失効チェックの両設定を検証。
ループバックでの認証失敗時に、暫定的なTLSストリームを破棄（Dispose）するよう修正し、決定的なクリーンアップを確認する回帰テストを追加（LoopbackServer.cs のヘルパー修正、SocketsHttpHandlerTest.cs に +71 行）。
変更ファイル:
- Configuration.Http.cs: badssl関連設定の削除（-3）
- HttpClientHandlerTest.AcceptAllCerts.cs: ループバック化（+20/-16）
- HttpClientHandlerTest.ServerCertificates.cs: 主要なテスト置き換え（+131/-48）
- LoopbackServer.cs、TestHelper.cs: ヘルパー調整
- SocketsHttpHandlerTest.cs: クリーンアップ回帰テスト追加

パフォーマンスへの影響

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

その他

WinHTTP の外部・コールバックなし失効テスト2件は意図的に残されています。WinHttpHandler はスコープ付きカスタムトラストを使えず、コールバック有効の代替ではネイティブWinHTTPの失効強制ではなくマネージドのチェーン検証をテストしてしまうためです。
検証結果（Windows x64）:
- build.cmd clr+libs -rc release 成功
- System.Net.Http の証明書クラス: 27件成功
- WinHTTP（net11.0-windows）HTTP/1.1・HTTP/2: 44件成功
- net481 の共有WinHTTP証明書テスト: 11件成功
- 証明書／クリーンアップの14シナリオを3回連続で再実行して成功
- クリーンアップの回帰テストは、ヘルパー修正前は失敗し、修正後に成功
Linux、macOS、モバイル、および残された外部WinHTTP失効テストは未実施です。

#135595 JIT: don't contain BITCAST under small local stores

作成者: @EgorBo
作成日時: 2026年10月11日 16:35:27(UTC)
マージ日時: 2026年10月13日 14:14:41(UTC)
ラベル: area-CodeGen-coreclr

概要

小さな型（byte/short など）への STORE_LCL_VAR / STORE_LCL_FLD は、ソース値を暗黙的に切り詰めます。しかし、BITCAST が contained 化されていると、コード生成がソース側のレジスタ（例: float）から元の幅のままストアしてしまい、隣接フィールドを上書きする問題がありました。本PRは、小さなローカルストアの配下では BITCAST を contained にしないようにして、この問題を修正します。

変更内容

src/coreclr/jit/lowerxarch.cpp（+2/-1）: x86/x64 の Lowering で、小さなストア配下の BITCAST の contain を抑止
src/coreclr/jit/lowerarmarch.cpp（+2/-1）: ARM/ARM64 で同様の修正
src/coreclr/jit/lowerloongarch64.cpp（+2/-1）: LoongArch64 で同様の修正
src/coreclr/jit/lowerriscv64.cpp（+2/-1）: RISC-V64 で同様の修正
src/tests/JIT/Regression_ro_2/Runtime_134054.cs（+37/-0）: 隣接する byte フィールドが破壊されないことを確認する回帰テストを追加

いずれもランタイム内部（JIT の Lowering フェーズ）の変更であり、公開APIへの影響はありません。

パフォーマンスへの影響

影響なし（作成者によれば diffs なし）。

その他

Copilot のレビューでは、追加された回帰テストが 16bit の short ストア経路をカバーしていない点が中程度の指摘として挙げられています（未解決）。

#135594 JIT: mark pseudo return buffer temp as multi-reg return

作成者: @EgorBo
作成日時: 2026年10月11日 16:35:26(UTC)
マージ日時: 2026年10月13日 14:14:46(UTC)
ラベル: area-CodeGen-coreclr

概要

戻り値バッファ経由で値を返す呼び出し結果を、自身の戻り値型がマルチレジスタ構造体（例: arm64のHFA）であるメソッドから返す場合、impFixupStructReturnType が作成する一時変数に lvIsMultiRegRet が設定されず、Lowering でアサートが発生する問題を修正します。該当の一時変数がマルチレジスタ戻り値の既存処理にフォールスルーするようにしました。

変更内容

src/coreclr/jit/importer.cpp（+1/-1）: 疑似的な戻り値バッファの一時変数を、既存のマルチレジスタ戻り値処理に流すよう変更
src/tests/JIT/Regression_ro_2/Runtime_134052.cs（+37/-0）: 戻り値バッファからHFAへのビットキャストを対象に、全フィールドを検証する回帰テストを追加

パフォーマンスへの影響

影響なし（作成者によるとdiffsなし）

その他

JIT内部の修正であり、公開APIや互換性への影響に関する記載はありません。

#135591 Fix QuicStream send buffer leak

作成者: @asad24-dev
作成日時: 2026年10月11日 15:37:58(UTC)
マージ日時: 2026年10月13日 17:30:27(UTC)
ラベル: area-System.Net.Quic community-contribution

概要

QuicStream の送信バッファがリークする問題の修正です（#135583）。MsQuicBuffers が struct であるため、_sendBuffers を MsQuicContextSafeHandle.Disposable に代入した時点で、ハンドル側にはボックス化されたコピーが渡されていました。このコピーは最初の送信でネイティブの QUIC_BUFFER 配列が確保される前のものです。そのためハンドル解放時には、実際のバッファを保持するインスタンスではなく、古いコピーが Dispose されていました。

MsQuicBuffers を sealed class に変更し、ストリームとセーフハンドルが同じバッファ所有者を共有するようにしました。

変更内容

src/libraries/System.Net.Quic/src/System/Net/Quic/Internal/MsQuicBuffers.cs: MsQuicBuffers を struct から sealed class に変更（+5/-5）
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicStream.cs: 1行の変更（+1/-1）。具体的な内容は提供情報に含まれていません
既存のセーフハンドルの破棄経路は変更しておらず、ネイティブバッファはストリームハンドルが実際に解放されるときにのみ解放されます。
作成者の検証結果:
- 修正前は回帰テストで問題が再現（Expected: 0, Actual: 1）
- 修正後は回帰テストが通過（1 test, 0 failures）
- アナライザー有効で System.Net.Quic のプロダクトビルドが成功

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載はありません）。ネイティブバッファのリークが解消される点は改善です。

その他

なし

#135547 Fix test89834 SIGBUS on macOS ARM64

作成者: @Copilot
作成日時: 2026年10月09日 22:45:35(UTC)
マージ日時: 2026年10月13日 20:32:04(UTC)
ラベル: area-Infrastructure

概要

macOS ARM64 の checked ビルド（GC/JIT ストレス）で test89834 が SIGBUS で終了する問題（100 を期待しているところ 138 が返る）の修正です。原因は CORINFO_HELP_BULK_WRITEBARRIER_SMALL ヘルパーにあるとされています。このヘルパーは non-GC として分類されていますが、最初の呼び出しが prestub に入り、GC を引き起こす可能性があり、GC hole となっていました。

変更内容

src/coreclr/inc/jithelpers.h: 1 行変更（+1/-1）
src/coreclr/vm/corelib.h: 1 行削除（+0/-1）
src/coreclr/vm/jithelpers.cpp: 1 行追加（+1/-0）

※提供された情報には差分の詳細が含まれていないため、各ファイルの具体的な変更内容は不明です。

パフォーマンスへの影響

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

その他

対象は CoreCLR の JIT ヘルパー分類（non-GC か否か）に関する内部実装で、公開 API や互換性への影響を示す記載はありません。
問題は macOS ARM64 の checked ビルドかつ GC/JIT ストレス下で確認されたものです。

#135477 Fix nullable struct deserialization across buffer boundaries

作成者: @eiriktsarpalis
作成日時: 2026年10月09日 07:52:51(UTC)
マージ日時: 2026年10月13日 12:59:29(UTC)
ラベル: area-System.Text.Json

概要

System.Text.Json のストリーミングデシリアライズで、nullable な構造体内の null メンバーの直後にバッファ境界が来ると、有効なJSONに対して JsonException が発生する問題の修正です。

原因は、ReadStack.Push() が最深部の中断されたフレームを復元する際に IsContinuation をクリアすることです。これにより NullableConverter<T> がメンバートークンを「null の nullable 値」として誤って扱っていました。修正では、その高速パスに入る条件として ObjectState.None を必須にしています。

変更内容

src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Converters/Value/NullableConverter.cs (+3/-1)
- null 値の高速パスに入る前に ObjectState.None を要求するよう変更
src/libraries/System.Text.Json/tests/System.Text.Json.Tests/Serialization/Pipe.ReadTests.cs (+76/-0)
- PipeReader を直接使ったテストを追加（セグメント化されたバッファ、1バイトずつのフラッシュ、途中で切れた入力）
src/libraries/System.Text.Json/tests/System.Text.Json.Tests/Serialization/Stream.ReadTests.cs (+87/-0)
- バッファ境界のスイープ、ショートリード、バッファ拡張のテストを追加
src/libraries/System.Text.Json/tests/System.Text.Json.Tests/Serialization/StreamTests.ChunkedReaderStream.cs (+8/-1)
- テスト用ストリームの調整

テストはリフレクションとソース生成メタデータの両方を対象としています。

パフォーマンスへの影響

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

その他

作成者によれば、Windows上で対象テスト96ケースが net11.0 と net481 の各フレームワークで成功し、修正を戻すとフレームワークごとに48件が失敗します。
System.Text.Json の6つのテストプロジェクトはすべて失敗0件で、既存のスキップ17件はそのままです。
このPRは GitHub Copilot を用いて作成されています。

#135476 [release/11.0] Handle TAR uid/gid values larger than int.MaxValue

作成者: @github-actions[bot]
作成日時: 2026年10月09日 07:51:49(UTC)
マージ日時: 2026年10月13日 11:23:16(UTC)
ラベル: Servicing-approved area-System.Formats.Tar

概要

System.Formats.Tar が、int.MaxValue を超える UID/GID を持つ TAR アーカイブを読み込む際に OverflowException をスローする問題の修正を release/11.0 へバックポートするものです（#134850 のバックポート）。

GNU tar 形式では UID/GID が int.MaxValue を超える値でエンコードされることがありますが、既知の UNIX プラットフォームではこれらの ID は 32bit 数値として定義されています。そのため、int.MaxValue を超える値を負数へオーバーフローさせて扱うことで、有効なアーカイブを読み込み・書き出し（ラウンドトリップ）できるようにしています。

変更内容

TarEntry.cs: UID/GID の扱いに関する変更（+2/-2）
TarHeader.cs: UID/GID 関連の変更（+6/-3）
TarHeader.Read.cs: ヘッダー読み込み時の UID/GID の解析処理を変更（+4/-4）
TarHeader.Write.cs: ヘッダー書き込み時の UID/GID の処理を変更（+22/-9）
TarHelpers.cs: 新規ヘルパー処理を追加（+32）
テスト追加:
- TarReader.Tests.cs: 大きな UID/GID を含むアーカイブの読み込みテスト（+120）
- TarWriter.WriteEntry.Entry.Roundtrip.Tests.cs: ラウンドトリップのテスト（+34）

影響範囲はライブラリ（System.Formats.Tar）の内部実装です。公開 API の変更は提供された情報からは確認できません。互換性への影響について、破壊的変更や非推奨化の記載はありません。回帰（Regression）ではなく、顧客報告（#127006）による修正です。リスクは Low とされています（変更が小さく、テストでカバーされているため）。

パフォーマンスへの影響

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

その他

Customer Impact として、このままでは該当アーカイブを外部実装やサードパーティ実装なしに処理できない点が挙げられています。

#135464 [Interpreter] Record the next instruction's ip before calling a managed helper

作成者: @pcshrosbree
作成日時: 2026年10月09日 03:08:29(UTC)
マージ日時: 2026年10月13日 06:48:33(UTC)
ラベル: community-contribution area-CodeGen-Interpreter-coreclr

概要

インタプリタ（src/coreclr/vm/interpexec.cpp）で、マネージドヘルパー呼び出しの前に「次の命令の ip」を pFrame->ip に記録するよう修正したPRです。

従来、INTOP_CALL_HELPER_* と INTOP_UNBOX_ANY[_GENERIC] のネイティブヘルパー呼び出し経路では、ヘルパー実行中も pFrame->ip が命令の先頭を指したままでした。ヘルパーがマネージドコードで例外を投げると、インタプリタフレームは faulting としてマークされず、SfiInitWorker/SfiNextWorker が ip をリターンアドレスとみなして STACKWALK_CONTROLPC_ADJUST_OFFSET を引きます。その結果、ヘルパー呼び出しが try 領域の最初の命令（.cctor を持つ型の静的フィールドアクセスでの静的ベースヘルパーなど）の場合、補正後の ip が領域の手前に落ち、ハンドラーが実行されませんでした。

INTOP_CALL や IL ターゲット側の経路は既に次命令の ip を記録していたため、ネイティブヘルパー経路も同様に ip を進めてからヘルパーを呼ぶようにしています。

変更内容

src/coreclr/vm/interpexec.cpp
- ネイティブヘルパー呼び出しの出口で ip を進めて pFrame->ip に保存してからヘルパーを呼ぶよう変更。
- GetPossiblyIndirectHelper のみが先に実行されるケースでは、各 case 冒頭の pFrame->ip = ip を削除。
- DoGenericLookup を先に呼ぶ5つのオペコード（INTOP_CALL_HELPER_P_G、P_GS、P_GA、V_AGS、INTOP_UNBOX_ANY_GENERIC）では、冒頭の pFrame->ip = ip を残しています。この lookup は例外や GC を起こし得ますが、その例外は C++ 例外で、InterpExecMethod の unwind-and-continue ハンドラーが捕捉してフレームを faulting にマークするため、命令先頭の ip が正しいためです。
src/tests/Regressions/coreclr/GitHub_135455/test135455.cs、test135455.csproj（新規）
- try/finally とそれを囲む try/catch の両方で、静的アクセスを領域の最初の命令に置くリグレッションテスト。
- 初回アクセス、記録済みの失敗を再スローするアクセス、共有ジェネリックのインスタンス化（INTOP_CALL_HELPER_P_G 経路）を検証。
- どのビルド構成でもアクセスが領域の最初の命令に残るよう、プロジェクトで Optimize を設定。

パフォーマンスへの影響

影響なし（記載された範囲では、パフォーマンスに関する言及はありません）。

その他

検証（Checked runtime、PRのベースコミット、JIT および DOTNET_InterpMode 1/2/3）
- linux-x64、osx-arm64、windows-x64 のすべてで、修正なしでは追加テストがインタプリタ下で失敗（TypeInitializationException が漏れる）し、Issue再現のケース1・2でハンドラーがスキップされます。修正後はいずれも通過し、ハンドラーが実行されます。
- INTOP_CALL_HELPER_P_P で命令先頭の保存に戻すとテストが3プラットフォームすべてで失敗します。JIT下では修正の有無にかかわらず通過します。
- 既存テスト Regressions/coreclr/GitHub_135234 も同じバグに該当し、osx-arm64 の InterpMode 1 と 3 で失敗していたものが修正後に通過します。
- JIT/interpreter は linux-x64 と osx-arm64 で通過。windows-x64 は、ネイティブテスト資産がビルドできず TestPInvoke を実行できなかったため、そこまでの通過に留まります。
同様に命令先頭を保存して呼び出す他の箇所は、以下の理由で今回変更していません。
- INTOP_NEWARR[_GENERIC]: 現状は try 領域の最初の命令になり得ませんが、コピー伝播が入ると到達可能になり得ます。
- async suspend 経路の continuation 割り当て: 常に await 呼び出しの直後で同じ領域内にあるため、補正後の ip がその呼び出し内に収まります。
- catch からの再開後のスレッドアボート dispatch: 別の大きな問題として #135463 で扱います。
作成者による注記：このPRはAI支援（Anthropic Claude、OpenAI Codexによるレビュー）で作成されています。

#135460 Add support for specifying load context in custom hosting APIs

作成者: @elinor-fung
作成日時: 2026年10月08日 23:56:44(UTC)
マージ日時: 2026年10月13日 19:25:33(UTC)
ラベル: area-Host

概要

ネイティブホスティングのカスタムコンポーネントホスティングAPIに、ロードコンテキストを指定できる機能を追加します。coreclr_load_context をコンポーネントホスティングAPIへ渡せるようになり、同一の識別子を持つコンポーネントは同じロードコンテキストを共有します。設計ドキュメント native-hosting-load-context.md のカスタムコンポーネントホスティング部分の実装であり、#133570 のフォローアップです。

変更内容

docs/design/features/native-hosting.md: ロードコンテキスト指定に関する記述の更新
ComponentActivator.cs: ロードコンテキストを受け取る形への処理変更
ComponentLoadContext.cs / ComponentLoadContextManager.cs: ロードコンテキストの管理・共有に関する変更
coreclr_delegates.h: ネイティブ側のデリゲート定義の更新
nativehost.cpp / host_context_test.cpp: ネイティブホストのテストコードを新APIに合わせて更新
LoadAssembly.cs / NativeHostingResultExtensions.cs: ロードコンテキスト指定の動作を検証するHostActivationテストを追加（+77行）

パフォーマンスへの影響

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

その他

公開されるネイティブホスティングAPI（coreclr_delegates.h）のシグネチャ・定義に関わる変更です。互換性への影響の有無は提供情報からは判断できません。

#135458 JIT: preserve value evaluation when expanding reference array stores

作成者: @EgorBo
作成日時: 2026年10月08日 23:47:49(UTC)
マージ日時: 2026年10月13日 14:15:21(UTC)
ラベル: area-CodeGen-coreclr

概要

JITのmorphフェーズで、参照型配列のストアヘルパー呼び出しを直接ストアに展開する際、副作用を持つオペランドを「配列 → インデックス → 値」の順に評価してから、配列のnullチェックと境界チェックを導入するよう修正します。importerでのspillは、ヘルパー呼び出しのままの段階では forward substitution により取り消され得るため、この順序保証を変換処理そのものに組み込んでいます。volatile読み取りのような「順序付けのみ」の副作用も対象に含めています（変換処理と、既存のインライン配列ストア用importer spillの両方）。

変更内容

src/coreclr/jit/morph.cpp（+15）: ヘルパー展開時に副作用を持つオペランドを配列/インデックス/値の順に評価してから、null・境界チェックを導入
src/coreclr/jit/importer.cpp（+1/-1）: 順序付けのみの副作用（volatile読み取りなど）を考慮するよう条件を変更
src/coreclr/jit/importercalls.cpp（+1/-1）: 同上の変更
src/tests/JIT/Regression_ro_2/Runtime_133860.cs（+48）: 例外の発生順序に関する回帰テストを追加

パフォーマンスへの影響

作成者によると、SPMIのdiffはほぼありません（"Almost no diffs"）。ベンチマーク結果は提示されていません。

その他

Copilotのレビューでは「変更推奨」とされ、以下の2点が指摘されています。
- （Medium）多次元配列のストアに相当するパスが未修正であり、spill条件に順序付け副作用を含めるべきではないか
- （Low）volatile読み取りを含む、配列チェックの評価順序に関する回帰テストが不足している

#135430 [cDAC] Map entry point to code start in GetMethodVarInfo; make ReJIT optional in IsVersionable

作成者: @lewing
作成日時: 2026年10月08日 16:00:19(UTC)
マージ日時: 2026年10月13日 10:09:40(UTC)
ラベル: area-Diagnostics-coreclr

概要

ポータブルエントリポイントを使うターゲット（CoreCLR WebAssembly など）向けに、cDAC の IDebugInfo.GetMethodVarInfo の2つの問題を修正します。

codeOffset を、メソッドのエントリポイント（ICodeVersions.GetNativeCode）ではなく、IExecutionManager.GetDiagnosticCodeStartFromEntryPoint（#134827）でコード開始位置にマッピングした値からの相対で計算するようにしました。このメソッドは、インタプリタメソッドならインタプリタのバイトコード、ポータブルエントリポイントなら R2R の仮想 IP を返し、それ以外はアドレスをそのまま返します。
IsVersionable が ReJIT コントラクトを必須としていたため、PROFILING_SUPPORTED が無効な wasm では GetMethodVarInfo が ContractMissingException を投げていました。コントラクトが存在しない場合は ReJIT 対象外として扱うよう、TryGetContract を使うように変更しました。

変更内容

DebugInfo_1.cs: GetMethodVarInfo のコードオフセット計算で、GetNativeCode の結果を GetDiagnosticCodeStartFromEntryPoint でマッピングするように変更（+4/-6）。
RuntimeTypeSystem_1.cs: IsVersionable で ReJIT コントラクトを任意化（TryGetContract を使用）（+3/-2）。
docs/design/datacontracts/DebugInfo.md、RuntimeTypeSystem.md: 上記の挙動に合わせてドキュメントを更新。
ExecutionManagerTests.cs: GetMethodVarInfo_CodeOffsetIsRelativeToDiagnosticCodeStart（恒等マッピングと別コード開始位置へのマッピングの theory）を追加。GetDebugInfo_R2R_NoDebugInfoSection_ReturnsNull は、マッピングに必要な FeatureFlags と PrecodeStubs を登録するように変更。
MethodDescTests.cs: IsVersionable_ReJITContractOptional（ReJIT コントラクトなし／無効／有効の theory）を追加。

パフォーマンスへの影響

影響なし

その他

ネイティブの ClrDataAccess::GetMethodVarInfo はインタプリタのエントリポイントのみをマッピングします。ネイティブ DAC は wasm 非対応のため、R2R ポータブルエントリポイントの場合に比較できるネイティブ側の挙動はありません。
作成者は、ReJIT を wasm で公開し IsEnabled() が false を返す代替案も提示しており、レビュアーの希望があれば切り替えるとしています。
CoreCLRContracts.ValidateForDataAccess は依然として IReJIT を要求するため、wasm では公式 DAC エントリポイントの検証が失敗します。この PR では変更せず、別のフォローアップが必要です。
検証: ./build.sh -s tools.cdactests -test が成功（Unit 3293/3293、DataGenerator 46/46、Usage 4/4）しました。ミューテーションチェックでは、元の実装に戻すと追加テストが失敗することを確認しています。
ライブの browser-wasm R2R ターゲットでは、エントリポイント 0x41ADC1C が診断開始位置 0x800104B3 にマッピングされ、GetMethodVarInfo はオフセット 0x2 を返しました。この検証に対する自動テストはありません。

#135424 Return raw bytes from ZstandardDictionary.Train

作成者: @rzikm
作成日時: 2026年10月08日 14:07:44(UTC)
マージ日時: 2026年10月13日 21:31:43(UTC)
ラベル: area-System.IO.Compression breaking-change needs-breaking-change-doc-created

概要

ZstandardDictionary.Train の戻り値を、品質3で準備済みの ZstandardDictionary から、呼び出し側が所有する辞書の生バイト列（byte[]）に変更します。従来は、準備済み辞書がエンコーダーの品質設定を上書きするため、別の品質を使いたい場合は Data を取り出して再度辞書を準備する必要がありました。この変更により、オフラインでのトレーニング/永続化と、品質ごとの辞書準備が分離されます。

byte[] data = ZstandardDictionary.Train(samples, sampleLengths, maxDictionarySize);
using ZstandardDictionary dictionary = ZstandardDictionary.Create(data, quality);

トレーニング時の検証、小サンプルに対する安全ガード、プール済みバッファのクリーンアップは変更されていません。準備済み辞書がエンコーダー品質より優先される点も従来どおりです。

変更内容

ref/System.IO.Compression.cs: Train の戻り値型を変更（参照アセンブリ宣言）
Zstandard.PlatformNotSupported.cs: Browser/WASI 向け宣言の戻り値型を変更
ZstandardDictionary.cs: 実装を変更し、生バイト列を返すようにした
README.md: ドキュメントを更新
ZstandardDictionaryTests.cs: 既存のトレーニングテストを新しい戻り値に合わせて更新（新規テストは追加されていません）

公開APIの戻り値型の変更です。

互換性への影響: ソース互換性・バイナリ互換性の両方を壊す変更（破壊的変更）です。作成者によると、マージ前にAPIレビューおよび破壊的変更の承認が必要なドラフトのプロトタイプであり、#59591 での当初の承認は旧来の ZstandardDictionary 戻り値型を前提としています。

パフォーマンスへの影響

ベンチマークは実施されていません。ランタイム性能に関わる変更の記載はありません。

参考として、Windows x64 での検証結果（作成者報告）では、再現手順は従来と同じ11,876バイトの辞書バイトを返しました。品質19で明示的に準備した場合の圧縮後サイズは5,073バイトで、品質3の6,312バイトより小さくなり、ラウンドトリップにも成功しています。

その他

検証結果（作成者報告）: System.IO.Compression のRelease ビルドは、すべての実装ターゲットフレームワークで通常のApiCompat検証を含めて成功しました。テストは2,999件が成功し、失敗・スキップはゼロでした。うち既存の辞書関連テスト17件も成功しています。
このPRはGitHub Copilotを用いて作成されたとの注記があります。

#135422 JIT: Preserve RHS writes in SIMD partial stores

作成者: @Copilot
作成日時: 2026年10月08日 13:45:54(UTC)
マージ日時: 2026年10月13日 14:14:59(UTC)
ラベル: area-Infrastructure

概要

v.X = Helper(ref v) のようなSIMDベクターの部分書き込み（partial store）において、モーフィング時にRHSより前にベクター全体が読み取られ、その後 WithElement でRHSの結果を反映することで、呼び出し先が他のフィールドに書き込んだ内容が上書きされてしまう問題（#135392）を修正します。RHSに永続的な副作用や順序依存の副作用がある場合は、WithElement への変換を行わず直接の部分書き込みを維持します。

変更内容

src/coreclr/jit/lclmorph.cpp（+6/-0）: RHSが永続的な副作用または順序付けの副作用を持つ場合に、直接の部分書き込みを維持するようモーフィングを変更。副作用のないRHSでは従来どおり WithElement を保持。
src/tests/JIT/Regression_ro_2/Runtime_135392.cs（+228/-0）: リグレッションテストを追加。numericsフィールド、SIMDのhalf、代入、副作用のないRHS、volatile読み取りの各ケースを含む。

パフォーマンスへの影響

ベンチマーク結果の記載はありません。副作用のないRHSでは WithElement の最適化が維持されるため、その場合の影響はないと考えられます。副作用を持つRHSでは直接の部分書き込みになるため、生成コードが変わる可能性があります（PR内に具体的な数値や評価はありません）。

その他

Copilotの自動レビューでは、アーキテクチャ横断のコード生成およびレジスタ割り当てへの影響について、人手によるレビューとランタイムでの検証が必要とされています（ビルドやテストは実行されていないとの記載）。未解決の指摘事項は0件です。
問題となるパターンの例（PR説明の v.X = Helper(ref v) に基づく）:

v.X = Helper(ref v); // Helperがvの他フィールドを書き換える場合

#135417 Allow CI scanner shell built-ins and extend inactivity watchdog

作成者: @vitek-karas
作成日時: 2026年10月08日 11:43:24(UTC)
マージ日時: 2026年10月13日 08:44:09(UTC)
ラベル: area-Infrastructure

概要

CI Outer-Loop Failure Scanner（ワークフロー）が、Bashのコマンド許可リストに read がなかったため実行できなかった問題に対応するPRです。スキャナーが実際に使用していたシェル組み込みコマンド（read と :）を許可し、無操作時の監視（inactivity watchdog）のタイムアウトを2分から10分へ延長します。ランタイム/ライブラリのコードやAPIへの変更はなく、CIワークフロー設定のみの変更です。

変更内容

.github/workflows/ci-failure-scan.md (+5/-1): Bashコマンド許可リストに read と : を追加し、inactivity watchdogを2分から10分に延長
.github/workflows/ci-failure-scan.lock.yml (+6/-2): 既存のgh-aw v0.86.2コンパイラで再生成したロック済みワークフロー。プロンプトとバージョン固定は変更なし。コンパイラの仕様により、非アクティブな失敗Issueの有効期限デフォルトが168時間に正規化される（失敗Issueレポートは引き続き無効）

補足:

全体の90分制限と2,500クレジット上限は変更なし
ウォッチドッグの延長は、静かな処理の早期中断を緩和するもので、フレームワーク側のスキャン完了検出の問題を解決するものではない

パフォーマンスへの影響

影響なし（ランタイムやライブラリへの影響なし）。CIスキャナーの実行時挙動のみに関わる変更です。

その他

検証結果（作成者による）:
- gh-aw固定バージョンでのコンパイルと git diff --check は成功
- Copilot CLI v1.0.90での権限回帰チェック8件がすべて成功
- 145秒の無出力操作で、旧2分設定では中断され、新10分設定では完了することを確認
- ローカルLinux ARM64 Docker環境で、10分設定の反映、36パイプラインのビルド一覧取得、コマンド権限拒否やウォッチドッグ終了が発生しないことを確認
エンドツーエンドでの完了は未検証。最後のDockerスキャンは、ローカルランナーの不具合で90分の期限を超過したため停止され、一部のCI証拠も取得できなかった。ローカルランナーの修正はこのPRに含まれていない。Docker検証はエージェントジョブのみで、Issueは公開されていない
検証用スクリプトやフィクスチャはセッションローカルで、PRには含まれない

#135414 WASI hello world with native AOT

作成者: @MichalStrehovsky
作成日時: 2026年10月08日 09:35:52(UTC)
マージ日時: 2026年10月13日 02:35:04(UTC)
ラベル: arch-wasm area-NativeAOT-coreclr

概要

WASI向けNative AOTでの「hello world」を成立させるため、Wasmオブジェクトライタが wasm-ld でリンク可能なリロケータブルオブジェクトを出力できるようにする変更です。linking（symbol-table / segment-info）メタデータ、CODEおよびマージ済みDATAのrelocationセクションを出力し、マネージドメソッド本体とコンパイラデータをWASI libcとリンクできるようにしています。

検証では、ランタイムなし・アロケーションなしの直接呼び出しプログラムが対象で、puts へのP/Invokeで "Hi" を出力し、wasmtime 上で正常終了（exit 0）することを確認しています。サンプルはリポジトリ内のrepro（zerosharp.cs）として提示されています。

[DllImport("*"), SuppressGCTransition]
static extern unsafe int puts(byte* str);

[UnmanagedCallersOnly(EntryPoint = "__main_argc_argv")]
static int NativeMain(int argc, byte** argv)
{
    Main();
    return 0;
}

static unsafe void Main()
{
    int abc = 'H' | 'i' << 8;
    puts((byte*)&abc);
}

変更内容

src/coreclr/jit/emitwasm.cpp：変更あり（+10/-4）。詳細な内容は提供情報からは不明です。
ObjectWriter/Wasm/WasmDataSection.cs：セグメントインデックスとエンコード済みコンテンツのオフセットを保持するように変更。
ObjectWriter/Wasm/WasmSection.cs：共有のカスタムセクションエンコーディングを用いる共通の IWasmSection リスト化に関連する変更（+35/-2）。
ObjectWriter/WasmRelocatableObjectWriter.cs：通常セクション、結合DATA、linkingメタデータ、relocationメタデータを、順序付き IWasmSection リストとして一括出力するよう再構成（+275/-137）。シリアライズ項目には Linking.md の用語に沿った注釈を付与。
ILCompiler.RyuJit/.../MethodCodeNode.cs：EHを持たないメソッドに対して空のfuncletリストを返すように変更。
Wasmメソッド本体は WasmCodeSection に配置し、本体間にネイティブのアライメントバイトが入らないようにしています。NativeAOTフレームにはリンカが割り当てる絶対関数テーブルスロットを使用します。

パフォーマンスへの影響

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

その他

作成者自身が明記している通り、遷移（transition）およびGCヘルパーはno-opであり、実際のランタイム初期化、GC、例外/funclet、デバッグ情報、CoreLib全体のサポートは今回の範囲外です。テストは追加されていません。
repro のビルド／実行には回避策が必要です：
- -O：アウトオブラインのP/Invokeスタブが未対応のfinally処理を使うのを回避
- --noscan：スキャナが System.Buffer 依存を解決できない問題を回避
- --codegenopt:JitMinOpts=1：RhpTrapThreads を参照するGCポールではなく、GCヘルパー呼び出しを使用させる
検証手順：ローカルビルドしたmanaged ILCで --targetarch:wasm --targetos:wasi を指定してコンパイルし、clang --target=wasm32-wasip1 と WASI sysroot（-lc）でリンク後、wasmtime run で実行し、"Hi" と改行が出力されることを確認しています。

#135411 Delete CodeHeapReserveForJumpStubs

作成者: @jkotas
作成日時: 2026年10月08日 06:43:47(UTC)
マージ日時: 2026年10月13日 02:43:40(UTC)
ラベル: area-VM-coreclr

概要

新しいprecode設計により、jump stubの確保を必ず成功させる必要がなくなったため、CodeHeapReserveForJumpStubs（jump stub用の予約領域）を削除するPRです。適切なアドレス範囲にjump stub用のメモリを確保できないごく稀なケースでは、確保失敗を NULL として伝播し、確保をリトライする方式に変更されています。

変更内容

src/coreclr/vm/codeman.cpp / codeman.h: jump stub用ヒープ予約の仕組みと、範囲指定のOOMを致命的エラーとして扱う処理を削除し、確保状態とjump stub関連APIを簡素化
src/coreclr/vm/dynamicmethod.cpp: 範囲指定の確保が満たせない場合に失敗を返すよう変更
src/coreclr/vm/jitinterface.cpp: 再配置処理を、NULL を返しうるjump stub確保に対応
src/coreclr/vm/amd64/cgenamd64.cpp / cgencpu.h: AMD64の動的ヘルパー生成で、確保失敗時に別アドレスでエミットし直すリトライ処理を追加し、再配置ヘルパーの契約を更新
src/coreclr/inc/clrconfigvalues.h: 不要になったjump stub関連の設定を削除
src/coreclr/dlls/mscorrc/mscorrc.rc / resource.h: 範囲OOM用のエラーメッセージとリソースIDを削除
src/coreclr/pal/src/map/virtual.cpp: 実行可能メモリ予約に関するコメントを更新
src/coreclr/debug/daccess/fntableaccess.h: 診断用のヒープレイアウトのミラー定義を同期
src/coreclr/vm/threads.h: 冗長なアクセス指定子を削除
docs/design/features/jump-stubs.md: 設計ドキュメントを大幅に更新（+88/-484）し、削除された設定や致命的失敗の記述を整理

全体として、削除行数が追加行数を大きく上回るコード簡素化のリファクタリングです。

パフォーマンスへの影響

影響なし（提供された情報にベンチマーク結果や性能に関する記載はありません）。

その他

公開APIの変更は確認できず、ランタイム（CoreCLR VM）内部の実装変更です。
Copilotのレビューでは、設計ドキュメントが削除済みの設定や致命的失敗の挙動を記述したままである点が指摘されていましたが、現在は解決済みとされています。
CoreCLRのコード確保とリトライの挙動は複数アーキテクチャにまたがるため、最終的にメンテナーによる確認が必要とされています。

#135237 Correct MetadataLoadContext binding docs and not-found message

作成者: @caraioniurie47
作成日時: 2026年10月05日 19:09:11(UTC)
マージ日時: 2026年10月13日 12:53:34(UTC)
ラベル: area-System.Reflection community-contribution

概要

MetadataLoadContext において、アセンブリをロードしてもその名前は束縛されず、名前は MetadataAssemblyResolver が返したアセンブリにのみ束縛される（dotnet/corefx#33734 以降の挙動）という実際の動作に合わせて、ドキュメントコメントとエラーメッセージを修正する変更です。ロード処理自体のロジックは変更していません。

変更内容

Strings.resx: FileNotFoundAssembly のメッセージを、リゾルバーがアセンブリを返さなかったこと、およびロード済みアセンブリはリゾルバーが返した場合にのみ名前に対して使われることを示す内容に変更。
MetadataLoadContext.Apis.cs: クラスおよび LoadFrom* のドキュメントコメントから「ロードすると名前が束縛される」という記述を削除。LoadFromAssemblyName 系には、リゾルバーが null を返した結果が記憶される旨を追記。誤字2か所（"bound by to"、"has already loaded been loaded"）も修正。
ResolveMethod.cs: 新規テスト ResolverReturnsNullForLoadedAssembly を追加。ロード済みアセンブリに対してリゾルバーが null を返すケースを検証。

パフォーマンスへの影響

影響なし

その他

マージされずにクローズされた #129050 の LoadFrom* ドキュメント修正を含みます。
公開ドキュメントは dotnet/dotnet-api-docs から生成されるため、同様の修正が dotnet/dotnet-api-docs#13154 にも含まれています。
作成者によると、System.Reflection.MetadataLoadContext.Tests は net11.0 と net481 で成功し、新規テストは LoadFromStreamCore でロード時の束縛を復活させると失敗します。

#135107 Use MoveToImmutable in ILLink.RoslynAnalyzer

作成者: @prozolic
作成日時: 2026年10月02日 16:00:10(UTC)
マージ日時: 2026年10月13日 16:13:15(UTC)
ラベル: linkable-framework community-contribution area-Tools-ILLink

概要

ILLink.RoslynAnalyzer と ILLink.Shared 内の ImmutableArray<T>.Builder の利用箇所で、ToImmutableArray の代わりに MoveToImmutable を呼び出すように変更するPRです。PR #134426 のフォローアップで、ILLink および ILCompiler.Compiler に適用された変更を ILLink.RoslynAnalyzer と ILLink.Shared にも反映しています。

変更内容

src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/MethodProxy.cs: メソッドのジェネリックパラメーターの変換を MoveToImmutable に変更（+1/-1）
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TypeProxy.cs: 型のジェネリックパラメーターの変換を MoveToImmutable に変更（+1/-1）
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TrimAnalysisMethodCallPattern.cs: 引数用ビルダーを正確な容量で事前確保し、MoveToImmutable で変換するよう変更（+4/-4）
src/tools/illink/src/ILLink.Shared/TrimAnalysis/HandleCallAction.cs: ジェネリックパラメーター値の変換を MoveToImmutable に変更（+1/-1）

いずれも内部実装（トリミング解析）の変更で、公開APIの変更ではありません。ビルダーの容量と要素数が一致している箇所で、コピーを伴わない転送に置き換えています。

パフォーマンスへの影響

ToImmutableArray によるコピーを避け、MoveToImmutable によるコピーなしの転送に置き換えることで、アロケーションの削減が見込まれます。ただし、PR内にベンチマーク結果や具体的な数値は記載されていません。Copilotのレビューでは、パフォーマンス最適化に対する計測の根拠（変更前後の測定結果）が不足している点が指摘されています（重要度: Low）。

その他

作成者は以下のコマンドでビルドとテストを実施したと記載しています。

./build.cmd -s libs.sfx -c Release /p:ToolsConfiguration=Debug
dotnet test src/tools/illink/test/ILLink.RoslynAnalyzer.Tests/ILLink.RoslynAnalyzer.Tests.csproj -c Debug
dotnet test src/coreclr/tools/aot/ILCompiler.Trimming.Tests/ILCompiler.Trimming.Tests.csproj -c Release

MoveToImmutable はビルダーの Count が Capacity と一致しない場合に例外をスローします。そのため、各変更箇所では容量が要素数と正確に一致している必要があります。

#135091 Fix DynamicCode_Jit test

作成者: @BrzVlad
作成日時: 2026年10月02日 10:47:46(UTC)
マージ日時: 2026年10月13日 09:19:56(UTC)
ラベル: area-System.Runtime

概要

RuntimeFeature.IsDynamicCodeCompiled のテスト（DynamicCode_Jit）が、インタープリターが有効な環境で誤って失敗する問題を修正するPRです。インタープリターが有効な場合に「動的コードがコンパイルされている（IsDynamicCodeCompiled == true）」と仮定しないよう、テストの前提を変更しています。

背景として、Apple/WASMターゲットを模倣するため --dynamiccodecompiled false を明示的に指定してビルドする構成が存在します。このテストは以前インタープリター上で無効化されていましたが、最近 #134762 で再び有効化されたため、上記構成で問題が顕在化したとのことです。

変更内容

src/libraries/System.Runtime/tests/System.Runtime.Tests/System/Runtime/CompilerServices/RuntimeFeatureTests.cs（+4/-0）
- インタープリターが有効な場合は、DynamicCode_Jit テストで動的コードのコンパイルが true であることを前提としないよう、4行を追加

変更はテストコードのみで、公開APIやランタイム/ライブラリの実装には影響しません。

パフォーマンスへの影響

影響なし

その他

なし

#135028 Reconfigure native CMake builds from scratch when the compiler inputs change

作成者: @lewing
作成日時: 2026年10月01日 15:09:40(UTC)
マージ日時: 2026年10月13日 09:35:28(UTC)
ラベル: area-Build-mono

概要

CMakeはビルドディレクトリの初回configure時にのみコンパイラを検出するため、その後にツールチェーンファイル・CC/CXX・emcmakeなどを変更しても反映されませんでした。WASI SDKやemsdkがバージョン別のツールキャッシュディレクトリに移行したことで、SDK更新後も既存のローカルビルドディレクトリが古いコンパイラを使い続け、#134992 の後に undefined symbol: __wasilibc_descriptor_deallocate といったリンクエラーが発生していました（CIは毎回新規configureのため影響なし）。

本PRでは、コンパイラ選択に関わる入力を <build dir>/cmake_compiler_inputs.txt に記録し、前回と差異があれば clean ターゲットを実行した上で --fresh 付きでconfigureし直すようにしました。

変更内容

eng/native/gen-buildsys.sh（+35/-1）
eng/native/gen-buildsys.cmd（+35/-4）

両スクリプトで、以下の入力を cmake_compiler_inputs.txt に記録して比較します。

ツールチェーンファイル（環境変数および -DCMAKE_TOOLCHAIN_FILE 引数）
CC、CXX
$CC --version の1行目（同一パスの背後でのXcode更新やパッケージアップグレードを検出）
emcmake などのラッパーを含む、解決済みのcmakeコマンド
Windowsでは VCToolsInstallDir

記録が前回と異なる場合の動作は以下のとおりです。

clean ターゲットを実行します。ninja/makeはコマンドラインが変わらない限りオブジェクトを再ビルドしないため、同一パスのコンパイラが置き換わった場合（Xcode更新など）にcleanが必要になります。
その後 --fresh を付けてconfigureします。

既存のビルドディレクトリにはまだ記録がないため、この変更後の初回ビルドでは --fresh による再configureのみが行われ、cleanは実行されません。

パフォーマンスへの影響

影響なし（コンパイラ入力に変化がない場合は従来どおりインクリメンタルビルドが維持されると、作成者はmacOSで確認しています）。入力が変わった場合のみ、clean＋再configureによりフルリビルドが発生します。

その他

作成者によるmacOSでの検証内容：WASI SDK 33.0 → 34.0（ネイティブライブラリとCoreCLR）、CLR_CC によるホストコンパイラ切り替え、XcodeからCommand Line Toolsへの切り替え、emsdkのバージョン変更。いずれも新しいコンパイラで再configureされ、変更なしのビルドはインクリメンタルのままでした。
gen-buildsys.cmd はWindows環境がなかったため実行確認されていません。

#134883 Add access to exception instance on stack

作成者: @Copilot
作成日時: 2026年09月29日 21:31:59(UTC)
マージ日時: 2026年10月13日 12:57:40(UTC)
ラベル: area-ExceptionHandling-coreclr

概要

承認済みの診断用API ExceptionHandling.GetCurrentException() を追加し、スタック上の例外インスタンス（処理中の例外およびcatch中の例外）へアクセスできるようにします。CoreCLR / NativeAOT で実装され、Mono では PlatformNotSupportedException をスローします。Fixes #89724。

変更内容

公開API: System.Runtime.cs の参照アセンブリと ExceptionHandling.cs（共通部）にAPIの宣言とドキュメントを追加。
CoreCLR:
- ExceptionHandling.CoreCLR.cs に実装を追加し、InternalCalls.cs で新しいQCallをインポート。
- qcallentrypoints.cpp / exceptionhandlingqcalls.h でQCallを登録・宣言。
- exceptionhandling.cpp で例外状態を公開し、exkind.h にcatchハンドラ状態を追加してアクティブなcatchを識別。
NativeAOT:
- ExceptionHandling.NativeAot.cs に実装を追加。
- Runtime.Base の ExceptionHandling.cs で処理中の例外を追跡・解決。
- EHHelpers.cpp で現在の例外情報をエクスポートし、RuntimeImports.cs でインポート。
Mono: ExceptionHandling.Mono.cs に常に PlatformNotSupportedException をスローするスタブを追加。
テスト: ExceptionHandlingTests.cs（+327行）で、catch、例外フィルター、再スロー、ネスト、ハードウェア例外、スレッド関連のセマンティクスを検証。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）。

その他

レビュー状況: CoreCLR / NativeAOT のメンテナーによるランタイム間の例外ディスパッチ変更の最終確認が必要とされています。
未解決の指摘: 公開ドキュメントに、Monoが常にスローする PlatformNotSupportedException の記載が欠けている点が指摘されています（Low severity）。
解決済みの指摘: System.Runtime.ExceptionServices のコンパイル項目をアルファベット順に並べる件は解決済みです。

#134749 Fix ILVerify entry stacks for nested exception filters

作成者: @pkuyo
作成日時: 2026年09月27日 17:36:06(UTC)
マージ日時: 2026年10月13日 18:45:22(UTC)
ラベル: area-Tools-ILVerification community-contribution

概要

ILVerify において、ネストされた例外フィルターのエントリースタック初期化が誤っており、正しいILに対して誤検出（false verification errors）が発生していた問題（#134711）を修正します。あわせて、例外ハンドリング（EH）領域の境界・重複・ネスト・節の順序・フィルターの終端などの検証を追加し、メソッドエントリがハンドラーやフィルター内にあるILを拒否するようになります。回帰テストも追加されています。

変更内容

ILImporter.Verify.cs（+45/-30）: フィルター／ハンドラーのエントリースタック初期化ロジックを修正。
ILImporter.ExceptionRegions.cs（+273/-0, 新規）: EH領域の境界、重複、ネスト、節の順序、フィルター終端（到達不能領域を含む）の検証を実装。
ILVerification.projitems（+1/-0）: 新規ファイルをプロジェクトに追加。
VerifierError.cs（+6/-0）: 新しい検証エラーコードを追加。
Strings.resx（+18/-0）: 新しい診断メッセージを追加。
ExceptionRegionTests.il（+932/-1）: 有効／無効なEHレイアウトを対象とした回帰テストを追加。

Copilotレビューによると、フィルター自身のリージョンを優先してエントリースタックを初期化し、フィルター／ハンドラーのエントリオフセットの競合を診断する変更が含まれています。

パフォーマンスへの影響

ベンチマーク結果の記載はありません。Copilotレビューでは、新しい全ペア比較による検証器の計算量が二次（O(n²)）で上限がない点が指摘されていましたが、その後解決済みとされています。ILVerifyはツールであり、ランタイムの実行性能への影響は記載されていません。

その他

互換性: 検証の範囲が広がるため、これまで通過していた不正なEHレイアウトのILがエラーとして報告される可能性があります（Copilotレビューは、この広い検証変更について最終的なメンテナーによる確認を推奨）。
Copilotレビューでは、ネストされた同一終端のtry領域でエントリーマーカーが失われる可能性（inclusive end の選択）と、検証範囲拡大に関するドキュメント不足も指摘されており、いずれも解決済みとされています。
作成者によると、本PRはCodexの支援を受けて作成されています。

#134423 Synchronize HTTP/2 queue-time test with connection publication

作成者: @rzikm
作成日時: 2026年09月22日 14:16:05(UTC)
マージ日時: 2026年10月13日 10:48:42(UTC)
ラベル: area-System.Net.Http

概要

HTTP/2 の TimeInQueue_RecordedForNewConnectionsOnly テストの不安定さ（flaky）を解消するための、テストのみの変更です。プール側は、最初の待機者へシグナルを送った後に接続を公開する場合があります。そのため、最初のレスポンス完了後すぐに接続が再利用可能になるとは限らず、後続の逐次リクエストが同じ接続上で正当にキュー待ちとなり、計測値が2〜3件になることがありました。キュー時間は「接続確立」だけでなく「利用可能な接続を待つ時間」を測るため、これは仕様上起こり得る挙動です。このPRでは、接続がプールに公開されるのを待ってから再利用を検証するようにしています。プロダクションコード、メトリクスのタグ、HTTP/1.1 / HTTP/3 の扱いは変更されません。

変更内容

src/libraries/System.Net.Http/tests/FunctionalTests/MetricsTest.cs（+48/-7）
- スコープを限定したプライベートな EventSource リスナーを追加し、最初のリクエストの URI とプール/接続の識別子を関連付け、その接続の公開（publication）を待機します。リクエストの関連付けより先に公開が起きた場合にも対応します。
- コールバックはブロックせず、待機にはタイムアウトが設定されています。
- 最初の計測値の duration とタグを検証し、最終的な期待カウントは 1 のままです。
- 保守上の依存として、非公開のトレースメッセージ Sending request: と Put HTTP2 connection in pool. に依存します。

パフォーマンスへの影響

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

その他

検証（Windows x64、Debug libraries / Release runtime）:
- ベースラインの clr+libs ビルドは成功。
- 強制スケジューリングのプローブで、元のテストに対し HttpClient / HttpMessageInvoker の両方で Actual 2 と Actual 3 を再現。修正後のテストは、公開の遅延、関連付け前の公開、無関係な Meter の分離を含む6つのコントロールに合格（プローブ自体は本PRに含まれません）。
- メトリクス関連の9フィクスチャ：298件成功、期待されるスキップ2件。
- 既存の飽和した HTTP/2 接続のキューテレメトリのコントロール：1件成功。
- NativeAOT の HTTP/2 メトリクスフィクスチャ：72件成功、既存スキップ4件。変更された両テストのバリアントが成功。
Linux/musl はローカルでは未実行です。フィルタなしで誤って実行した NativeAOT 呼び出しは、対象フィクスチャ外の失敗により中断されたため、ライブラリ全体のクリーンな実行結果は主張されていません。最終的にフィルタ指定した実行は成功しています。
本変更と説明文は GitHub Copilot により生成されたと記載されています。

#133670 Fix ILVerify validation of interface MethodImpl bodies

作成者: @pkuyo
作成日時: 2026年09月11日 08:11:15(UTC)
マージ日時: 2026年10月13日 03:03:38(UTC)
ラベル: area-Tools-ILVerification

概要

ILVerifyにおけるインターフェース MethodImpl ボディの検証を修正するPRです（Fixes #133500）。

インターフェース解決の前に、非virtualなインスタンス MethodImpl ボディを拒否するようにしました。解決結果がvirtualな基底メソッドを返すことで、不正なマッピングが隠れてしまう問題への対処です。
staticインターフェースメソッドについては静的リゾルバを使用し、有効な非virtual実装を許容します。
回帰テストを追加しています。

変更内容

src/coreclr/tools/ILVerification/TypeVerifier.cs (+59/-3): MethodImpl の検証ロジックと、static用の解決処理を追加
src/coreclr/tools/ILVerification/VerifierError.cs (+2/-0): 新しいエラーコード（InvalidMethodImpl 診断）を定義
src/coreclr/tools/ILVerification/Strings.resx (+6/-0): 診断メッセージ用のリソース文字列を追加
src/coreclr/tools/ILVerification.Tests/ILTests/InterfaceImplementation.il (+540/-0): 有効・無効の回帰テストケース（IL）を追加

パフォーマンスへの影響

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

その他

Copilotレビューでは、抽象型・デフォルトインターフェースメソッド・継承されたインターフェースのみを持つ型では MethodImpl 検証がスキップされたままである点や、継承された非virtualな MethodImpl ボディが基底のvirtualスロットへの解決で隠れうる点が指摘されています。
診断の理由文字列をインラインコードからリソースへ移す指摘がありましたが、最新のレビューでは解決済みとされています。
対象はILVerifyの検証ロジックで、公開APIの変更や破壊的変更に関する記載はありません。

#131826 [APX] Add Jmpabs support.

作成者: @DeepakRajendrakumaran
作成日時: 2026年08月04日 18:27:42(UTC)
マージ日時: 2026年10月13日 21:50:28(UTC)
ラベル: area-CodeGen-coreclr community-contribution apx

概要

AMD64上のvirtual call stubに、Intel APX（Advanced Performance Extensions）のJMPABS命令（D5 00 A1 + 8バイトアドレス）のサポートを追加するPRです。従来の mov rax, imm64; jmp rax による64ビット絶対ジャンプを JMPABS に置き換え、スタブサイズ縮小と命令フェッチ効率の改善を狙っています。実行時に IsJmpAbsAvailable()（InstructionSet_APX の有無）で判定し、APX非対応環境では従来のエンコードにフォールバックします。なお、当初含まれていたJITエミッタ側の変更は、レビューフィードバックにより取り下げられています。

変更内容

src/coreclr/vm/amd64/cgenamd64.cpp / cgencpu.h
- 生の JMPABS 命令（11バイト）を出力する emitJmpAbsJump() を追加
- emitBackToBackJump() を、利用可能なら JMPABS、不可なら従来エンコードを使うように変更（どちらも12バイト。APX側は jmpabs＋nop で揃える）
- IsJmpAbsAvailable() による実行時のCPU機能検出を追加
- 不要になった EncodeLoadAndJumpThunk() を削除
src/coreclr/vm/amd64/virtualcallstubcpu.hpp
- DispatchStubShort にAPXエンコード経路（jne rel32; nop; jmpabs imm64、従来と同じ18バイト）を追加
- DispatchStubLong にもAPX対応のレイアウトが入り、サイズが40→48バイトに増加
- DispatchStubShort_offsetof_failDisplBase マクロが誤った構造体型（DispatchStubLong）を参照していた問題を修正
src/coreclr/inc/dacvars.h、ceemain.cpp、codeman.cpp、SOSDacImpl.cs
- 関連する小規模な調整（DAC変数、初期化、cDAC側）

パフォーマンスへの影響

狙いは mov rax, imm64; jmp rax の2命令を単一命令にすることによる、命令フェッチ効率の改善です。
作成者はNOPパディングで従来とスタブサイズを揃えているため、short系スタブでのサイズ縮小は実際には発生していません。
ベンチマーク結果などの具体的な数値はPR内に示されていません。レビューでも、APX/従来の両レイアウトでの性能計測の追加が求められています。
DispatchStubLong は40→48バイトに増加しており、レビューではこれがメモリコストになる点が指摘されています。

その他

テスト: 作成者はAPX有効/無効でのライブラリテストと src/tests を実施し、非APXハードウェアでの回帰がないことを確認しています。ただしAPX対応ハードウェアでの実行検証は示されていません。
未解決のレビュー指摘（Copilotレビュー時点）:
- デバッガのpatch-skipデコーダが新しい D5 00 A1 命令を認識しない可能性がある（High）
- APX専用のレイアウトやブランチ変位を検証するテストがない（非APX環境では通らないため）
- isJmpAbsEncoding() が別のunionメンバー _bytes を読んでエンコード判定している
- DispatchStubLong のAPX版で jne の変位基点が誤っているとの指摘（jne rel32 の変位は命令の次のアドレス基準）
作成者による未決事項:
- JMPABS の3バイトプレフィックスにより即値のオフセットが+2から+3にずれ、8バイトアライメントが崩れる可能性があるため、DispatchStubLong の最適化を見送るか
- crossgen/ReadyToRun向けに、実行時検出に加えてコンパイル時やツールチェーン側の確認が必要か

注意点

目次

カテゴリ別PR一覧

ラベル別 Pull Request 数（上位4）

ラベル別PR一覧

#135712 Fix default servicing directory root on Unix

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135692 JIT: Preserve Half estimate ISA dependencies in ReadyToRun

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135686 Emit a zero-offset local address as a mov

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135685 Remove the redundant jump in the HW intrinsic jump table fallback

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135677 Disable Runtime_133581 on Mono

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135668 Correct decimal conversions to Half and BFloat16

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135666 Enable normal-completion finally emission for NativeAOT Wasm

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135662 [manual] Merge release/9.0-staging into release/9.0

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135661 [manual] Merge release/8.0-staging into release/8.0

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135644 Read metadata stream count as unsigned in MetadataReader

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135643 [release/11.0] Give the nested process chain in ProcessWaitingTests depth-proportional wait budgets

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135624 Kill process tree descendants before ancestors on Unix

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#135618 Replace badssl HTTP certificate tests with loopback servers

概要

変更内容