Pull Request on 2026年09月12日

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

注意点

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



#133781 Remove FEATURE_COUNT_GC_WRITE_BARRIERS due to compilation errors

概要

FEATURE_COUNT_GC_WRITE_BARRIERS フィーチャーフラグを削除し、コンパイルエラーを解決するPRです。GC書き込みバリア自体は保持しながら、廃止された計数計測コード、フィーチャースイッチ、バリア分類タイプを削除し、ランタイムコンパイラ(JIT)全体を簡潔化します。

変更内容

  • coreclr/inc/switches.h, inc/corjit.h: FEATURE_COUNT_GC_WRITE_BARRIERS フィーチャーマクロとバリア分類列挙型(GCWriteBarrierKind など)を削除
  • coreclr/vm/gchelpers.cpp: バリア計数計測用のインストルメンテーション(117行削除)を移除
  • coreclr/vm/jitinterface.h: GCヘルパー宣言を標準形に簡潔化
  • JIT CodeGen全体: x86/x64、ARM、ARM64、RISC-V、LoongArch64、WASMの各アーキテクチャ固有の実装で、バリア呼び出し箇所を更新し、廃止されたコメントを削除
  • coreclr/jit/codegencommon.cpp: バリア発行ロジックを簡潔化(73行削除、3行追加)

パフォーマンスへの影響

影響なし(計数計測コードの削除により若干のコード量削減が見込まれますが、GC書き込みバリアそのものの挙動は変わりません)

関連Issue

#133780

その他

  • PR作成者により、フィーチャー固有コードの検査、ベースラインビルド完了、フォーマット・セキュリティレビュー実施が報告されています
  • Copilot AIアシスタントによるレビューでは「WIP状態で承認準備が曖昧」との指摘がなされています

#133774 Fix Mono Windows x64 hardware exception continuations

概要

Windows x64 Mono MiniJIT環境で、ハードウェア例外継続時にOSの例外継続アドレス検証によりFAST_FAIL_SET_CONTEXT_DENIEDで プロセスが終了する問題を修正します。ネイティブランタイムエントリポイント経由で復帰させることで、Monoの既存トランポリン機構を利用して管理対象ハンドラコンテキストを正しく復元できるようにしています。

変更内容

  • exceptions-amd64.c: ハードウェア例外継続処理を実装。スレッドローカルストレージに解決済みマネージハンドラコンテキストを保存し、ネイティブエントリポイント経由でコンテキスト復元を行います。Win64スタックアライメントと引数ホームエリアの提供、スタックオーバーフロー復元コンテキストの分離を実施
  • HardwareEh.cs: ネストされたハードウェア例外のリグレッション回避テスト追加(ゼロ除算、オーバーフロー、null参照例外を フィルタ/finally内で反復)
  • runtime.yml: Windows x64 MiniJIT ランタイムテストレーン復旧(#133747により無効化されていたもの)

パフォーマンスへの影響

明示的スロー測定で有意な性能低下なし:ベースライン 2.070 µs vs 対象版 2.008 µs(測定誤差範囲内)。ハードウェア例外スロー経路は未修正ランタイムで終了するため、スループット比較不可。

関連Issue

#133702
#133747

その他

本修正はプロセスミティゲーション設定変更やCET汎用サポート追加ではなく、Mono MiniJIT固有の例外継続ハンドリング修正です。SIMD状態復元とスタックオーバーフロー対応がコミュニティレビュー時に指摘されています。


#133769 [release/11.0] Emit TaskWaitBegin and TaskWaitEnd for RuntimeAsync suspensions

概要

RuntimeAsync操作がTPL(Task Parallel Library)の待機関係を正しく発行していない問題を修正します。RuntimeAsync suspensionが発生した際に、アクティブなRuntimeAsyncタスクと待機対象のタスク間の因果関係を示すTaskWaitBeginとTaskWaitEndイベントを新たに発行するようになります。これにより、TPLイベントストリームの消費者が完全な因果活動データを取得でき、プロセス境界を越えた非同期関係の再構築が可能になります。

変更内容

  • AsyncHelpers.CoreCLR.cs: RuntimeAsync suspensionでTaskWaitBeginとTaskWaitEndイベント発行機能を追加(+44/-7)

    • 既存のTPLイベント型を活用し、RuntimeAsync診断計測が有効で対応するTPLイベントレベル/キーワードが有効な場合のみイベントを発行
  • RuntimeAsyncTests.cs: 包括的なユニットテストを追加(+214/-2)

    • begin/end イベントペイロードと順序検証
    • faultedおよびcancelledタスクのカバレッジ
    • TPLイベント無効時のタスクID割り当て回避の検証
    • RuntimeAsync診断計測無効時にTPL待機イベントが発行されないことの検証
    • RuntimeAsync ETW統合テスト(x64/x86クロスプロセスシナリオ含む)が16/16合格

パフォーマンスへの影響

影響なし。イベント発行は既に有効な診断計測とTPLイベントが有効な場合に限定され、タスクスケジューリング、継続実行、結果伝播、例外処理の動作には変更がありません。

関連Issue

#133028(オリジナルPR)

その他

  • これはrelease/11.0へのバックポート版です
  • リスク評価:低。既存機能の拡張で、スケジューリング等の動作変更なし
  • 回帰ではなく、.NET 11初期ビルドで欠落していたRuntimeAsync イベントカバレッジの追加です

#133747 Temporarily disable Windows x64 Mono MiniJIT runtime tests

概要

Windows x64 Mono MiniJIT ランタイムテストパイプラインの一時的な無効化。Issue #133702で報告されたFAST_FAIL_SET_CONTEXT_DENIEDエラーにより46個のプロセスレベルタスクで繰り返し失敗している当該テストレグを、CIパイプライン設定から削除し、根本原因の調査期間中の一時的な緩和策として機能させます。Linux/macOS MiniJITテスト、Windows Monoライブラリテスト、その他Windows対応テストは変更されません。

変更内容

  • eng/pipelines/runtime.yml: Windows x64 AllSubsets_Mono_Minijit_RuntimeTestsマトリックスエントリを削除(-38行)、Issue #133702の追跡情報とパイプライン再有効化の要件を記録するコメントを追加(+2行)

パフォーマンスへの影響

影響なし(CI/CDパイプラインスケジューリングのみの変更で、製品ビルドやランタイムテストの実行コードは変更なし)

関連Issue

#133702

その他

  • 本PRは製品修正ではなく一時的なCI緩和措置です。Issue #133702は対応中のまま保持される必要があります。
  • 検証済み:修正YAMLのパース完了、構造的な差分はWindows x64 MiniJITランタイムテストマトリックスエントリの削除のみ、その他パイプラインノードは変更なし
  • GitHub Copilot生成PR

#133727 JIT: Preserve 64-bit bit-count value numbers

概要

JITコンパイラの64ビット ビットカウント組み込み関数(PopCount、LeadingZeroCount、TrailingZeroCount)の定数畳み込み時に、TYP_LONG 値番号を保持するように修正。Issue #133560を解決します。

変更内容

  • src/coreclr/jit/valuenum.cpp: 64ビット ビットカウント組み込み関数の定数畳み込み処理で、TYP_LONG 型の値番号を正しく保持するよう修正(+2/-2)
  • src/tests/JIT/Regression/JitBlue/Runtime_133560/Runtime_133560.cs: 符号付き・符号なしのPopCount、LeadingZeroCount、TrailingZeroCountに対する64ビット レグレッション テストケースを追加(+41)

パフォーマンスへの影響

影響なし(バグ修正のため、コードジェネレーション精度の向上)

関連Issue

#133560

その他

  • JIT(すべてのビルド構成)、x64ネイティブ、WASM Crossgen2での動作確認済み
  • 内部実装(JIT値番号化)の修正で、公開APIへの影響なし

#133709 Fix scalar-typed SIMD operands in Dot and mask inversion lowering

概要

JITコンパイラにおけるSIMD操作の不正な低水準化を修正しました。浮動小数点CreateScalarUnsafeの除去により、スカラー型のオペランドがLIRに残される一方、ハードウェア固有の命令コンシューマーはこれをベクトルレジスタとして読み込むため、Dot演算とマスク反転の2つの処理パスで不整合が発生していました。

変更内容

  • lowerxarch.cpp: Dot演算の乗算低水準化を修正。gtNewSimdBinOpNodeの代わりにGetHWIntrinsicIdForBinOpでベクトル乗算を選択し、ハードウェア固有の命令を直接構築することで、LIR外の子ノード生成を防止しました。

  • gentree.cpp: マスク反転時の比較ID検索を修正。スカラー浮動小数点オペランドを受け付けるようにLIRアサーションを更新し、HIRの正確なベクトル型を保持。命令選択やスカラースピルサイズは変更なし。

  • 回帰テスト: Runtime_133551.cs(float/doubleのDot操作、128/256ビット、両オペランド順序、スカラー乗除演算制御)とRuntime_133554.cs(512ビット選択、等値/不等値/NaN値)の集中テストを追加。

パフォーマンスへの影響

影響なし。修正は正確性の問題であり、生成される命令シーケンスは変わりません。ネイティブおよびAVX設定で、生成されたディスアセンブリは直接的なハードウェア固有命令ID実装と一致することを確認。

関連Issue

#133551
#133554

その他

  • Checked JITで両方のアサーション失敗を再現し、Windows x64環境でネイティブISA、AVX-512無効化、AVX無効化、ハードウェア固有命令無効化、レジスタストレスの各条件下で8つの回帰テストがすべて成功することを検証。
  • Copilotレビューより:回帰テスト用のヘルパーにAggressiveOptimization属性の追加が推奨されています。

#133646 JIT: fix checked subtraction loop unrolling

概要

チェック付き減算ループのアンローリング時に、減算ステップを加算形式に正規化し、拡張算術を使用することで int.MinValue の否定時の未定義動作を防ぐ修正です。ループ方向と繰り返し回数の計算を正確に行います。

変更内容

  • src/coreclr/jit/optimizer.cpp: 減算インクリメントを加算ステップに正規化する処理を追加。拡張算術を使用して int.MinValue の否定時の安全性を確保し、ループ方向と繰り返し数の計算ロジックを改善。
  • src/tests/JIT/Regression/JitBlue/Runtime_133583/Runtime_133583.cs: チェック付き減算ループとオーバーフロー動作に関する回帰テストを追加。
  • src/tests/JIT/Regression/JitBlue/Runtime_133583/Runtime_133583.csproj: 回帰テストの設定(非階層化、独立実行)。

パフォーマンスへの影響

影響なし

関連Issue

#133583

その他

  • JIT内部実装(ランタイム最適化)の修正で、公開APIへの影響なし
  • Windows x64 Checked JIT でのSuperPMI検証済み(987,559コンテキストで差分なし)
  • 既存の JIT/Directed/UnrollLoop/loop2_cs_ro テストも合格

#133546 Fix assumptions about PEP from the JIT / aot compiler code

概要

JITおよび共有AOTコンパイラコードがPortable Entry Points (PEP)を常に使用することを前提としていた仮定を修正するPRです。NativeAOTではPEPが使用されないため、PEP固有の動作をJITフラグの有無や#ifdefで条件分岐するように変更しています。また、getWasmTypeSymbolを共有のCorInfoImpl.csに移動しています。

変更内容

  • WasmLowering.cs: Wasm署名構築時のPEPパラメータ出力をReadyToRunビルドに限定
  • CorInfoImpl.cs (共有): getWasmTypeSymbolの共有実装を追加
  • CorInfoImpl.RyuJit.cs / CorInfoImpl.ReadyToRun.cs: 重複していたNativeAOTおよびReadyToRun固有のgetWasmTypeSymbolスタブを削除
  • NodeFactory.cs: Wasm型ノード生成のためWasmTypeNode(CorInfoWasmType[])オーバーロードを追加
  • lowerwasm.cpp: 直接呼び出し適格性をPEP JITフラグに依存させるように変更(常に間接呼び出しを強制するのではなく)
  • codegenwasm.cpp: PEPフラグに基づいて直接ヘルパーコール用のアドレスを許可し、ヘルパー署名/PEPプッシュを条件付きで調整

パフォーマンスへの影響

NativeAOT環境下でPEPを使用しない直接呼び出しが可能になることで、呼び出しのオーバーヘッド削減の可能性があります。ただし具体的なベンチマーク数値は提供されていません。

関連Issue

なし

その他

Copilot reviewerによる指摘事項:

  • 共有getWasmTypeSymbol内のspanの長さに関するnuint→intキャストがチェックなしで実行されており、オーバーフロー時の危険性がある。チェック済みキャストと境界チェックを追加することを推奨
  • NativeAOT環境でのPEP削除に伴う署名変更(末尾のp削除)が既存のReadyToRun向けWasm署名テストでは検証されていない。NativeAOT向けのテストケース追加を推奨
  • XMLコメントがNativeAOTでもPEパラメータを含むと説明しており、実装とドキュメントが不一致。ドキュメントの更新を推奨

#133146 Use external method thunks for Wasm R2R virtual dispatch

  • 作成者: @davidwrighton
  • 作成日時: 2026年09月03日 03:40:30(UTC)
  • マージ日時: 2026年09月12日 04:57:27(UTC)
  • ラベル: area-ReadyToRun

概要

WebAssembly上のReadyToRun(R2R)クラス仮想呼び出しを外部メソッドインポートthunk/fixupパスを通じて実行し、その後、動的に発行される仮想ディスパッチポータブルエントリポイント経由でvtableオフセットによる後続呼び出しを転送する機構を実装しました。初回呼び出しは通常のWasmImportThunkとExternalMethodFixupWorkerを経由し、適切なクラス仮想呼び出しについてはvtableスロットを解決してR2R呼び出し用にメソッドを準備し、対応するVthunkを検索して、ポータブルエントリポイントを動的に割り当て発行します。その後の呼び出しはパック化されたvtableオフセットを通じてターゲットをロードします。

変更内容

  • JIT呼び出し規約(morph.cpp, importercalls.cpp): Wasm上のスタブディスパッチ呼び出しからVirtualStubCell隠し引数を削除
  • Crossgen2 R2Rコード生成:
    • WasmVirtualDispatchThunkNode.cs(新規): 仮想ディスパッチthunkコード生成
    • CorInfoImpl.ReadyToRun.cs: 適格クラス仮想呼び出しのみをスタブディスパッチにルーティング
    • WasmImportThunk.cs: 仮想呼び出しインポートを許可
    • ReadyToRunCodegenNodeFactory.cs: 仮想ディスパッチthunkノードキャッシュを追加
  • VM実行時fixup(prestub.cpp): ExternalMethodFixupWorkerでREADYTORUN_VIRTUAL_DISPATCH_PORTABLE_ENTRYPOINTを発行
  • Wasm補助関数(helpers.cpp/hpp): GetVirtualDispatchThunk実装
  • テスト追加: WasmVirtualDispatch.cs(新規)、mixed.cs拡張、R2RTestSuites.cs検証追加
  • ドキュメント: R2R形式仕様を更新

パフォーマンスへの影響

改善顕著:

  • 単形呼び出し: 51.54 ns → 20.78 ns(59.68%削減、スループット2.48倍)
  • 二形呼び出し: 50.83 ns → 20.85 ns(58.98%削減、スループット2.44倍)

標準偏差は安定(単形: 0.32→0.28 ns、二形: 0.09→0.04 ns)

バイナリサイズ削減:

  • System.Private.CoreLib.wasm: -142,923 bytes (-0.49%)
  • Wasm CODE: -127,503 bytes (-0.88%)

関連Issue

なし

その他

実装の特徴:

  • インターフェース、配列、真の汎用仮想メソッドは既存LDVIRTFTNパスを継続使用
  • 非汎用仮想メソッド(汎用型で宣言)と共有汎用コード内の制約なし/制約付きクラス仮想呼び出しが対象
  • 生成thunkはWasm関数型のみで鍵化(ABI等価なシグネチャを共有)

**レビュー指摘


#133028 Emit TaskWaitBegin and TaskWaitEnd for RuntimeAsync suspensions

概要

RuntimeAsync サスペンション時に TaskWaitBegin ETW イベントを発行し、デバッガーが Task オブジェクトを列挙することなく、RuntimeAsync "current task" と awaited Task の関係を観察できるようにします。awaited Task を RuntimeAsyncTaskContinuation から抽出し、非同期デバッガー計測が有効な場合に InstrumentedHandleSuspended 内でイベントを発行します。

変更内容

  • AsyncHelpers.CoreCLR.cs: InstrumentedHandleSuspended で awaited Task を RuntimeAsyncTaskContinuation から抽出し、TplEventSource.Log.TaskWaitBegin() を発行。また ResumeAsyncContext で対応する TaskWaitEnd を発行(ただし制限あり)
  • RuntimeAsyncTests.cs: RuntimeAsync_TaskWaitEvents テストケースを追加し、TaskWaitBegin/TaskWaitEnd イベントの発行を検証

パフォーマンスへの影響

影響なし(ETW イベント発行のオーバーヘッドは既存の計測インフラストラクチャ内)

関連Issue

なし

その他

⚠️ 重要な問題が残存しており、未解決のコメントがあります:

  1. 不完全なイベントペアリング: TaskWaitBegin は発行されますが、対応する TaskWaitContinuationComplete が発行されていません。既存の await パス(TaskAwaiter.OutputWaitEtwEvents)と異なり、begin/end ペアが対応していないため、ETW タイムライン可視化や期間計算が破損する可能性があります。

  2. 計測有効化後のサスペンションでの問題: 計測有効化前にサスペンションが開始された場合、TaskWaitBegin が発行されていないのに後で TaskWaitEnd が発行され、不完全な ETW ストリームが生じます。継続ごとに「begin が発行されたか」の状態を追跡する必要があります。

  3. テストの時間依存性: イベント配信が非同期であるため、タイミング敏感なアサーションで不安定になる可能性があります。


目次