Pull Request on 2026年05月02日

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

注意点

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



#127673 Remove DacDbi GetAppDomainObject API from native and cDAC

概要

デバッガインターフェース層(DAC/DBI)から未使用のGetAppDomainObject APIを削除するクリーンアップPRです。GetRawExposedObjectHandleForDebugger()が常にNULLを返していたため、このAPIは実質的にno-opでした。ネイティブCOM契約(IDL + 抽象インターフェース実装)とマネージドcDAC投影層の両方から削除されます。

変更内容

  • DAC/DBI ネイティブ層: IDL契約、抽象インターフェース定義、DacDbiImpl実装からGetAppDomainObjectを削除
  • マネージドcDAC層: IDacDbiInterfaceおよびDacDbiImpl(旧版フォールバック実装)から削除
  • AppDomain層: GetRawExposedObjectHandleForDebugger()メソッドを削除(唯一の呼び出し元)
  • CordbAppDomain層: GetObject()メソッドを簡略化(削除によって発生した不要コードを除去)

パフォーマンスへの影響

影響なし(不使用APIの削除のため、実行時パフォーマンスは変化なし。コード削減により若干のバイナリサイズ削減)

関連Issue

なし

その他

  • 破壊的変更: GetAppDomainObject APIの削除は公開デバッガAPIの削除ですが、APIが常にNULLを返していたため、実際の動作変化はありません
  • このPRは死コード除去(dead code elimination)を目的とした保守作業です
  • すべての変更は削除(-のみ)で構成されています

#127661 Update fgMorphSmpOp to canonicalize commutative and compare ops at the start of POST-ORDER

概要

CoreCLR JITのfgMorphSmpOp関数を修正し、POST-ORDER処理の開始時に交換可能(commutative)な演算子と比較演算子のオペランド順序を正規化するようにしました。これにより、定数が予測可能な位置に配置され、POST-ORDER最適化の一貫性が向上します。

変更内容

  • morph.cpp: fgMorphSmpOpのPOST-ORDER処理で、左オペランドが定数の場合にオペランドをスワップして交換可能演算子と比較演算子を正規化
  • morph.cpp: ((a % pow2) ==/!= 0) => (a & (pow2-1) ==/!= 0)パターン最適化をPRE-ORDERからGT_EQ/GT_NE POST-ORDER処理に移動
  • compiler.h: 値番号付けCSE(Value-Number CSE)フェーズ中にfgMorphTreeが呼び出されないことをアサートで保証する仮定を追加

パフォーマンスへの影響

影響なし(コード生成の最適化パターンの正規化であり、パフォーマンス数値への記載がない)

関連Issue

なし

その他

本変更はJITコンパイラの内部実装(morph処理)に限定されており、公開APIへの互換性影響はありません。複数のレビュアー(EgorBo含む)による承認を経ています。


#127660 Don't report a interp->native transition when it is done from a pinvoke method

概要

インタープリタでP/Invoke呼び出し時に管理↔非管理遷移イベントが二重報告される問題を修正します。#126509によるP/Invoke処理の変更後、transient ILがILStubではなくP/Invokeメソッド自体に属するようになったため、遷移イベントが2回報告されていました。P/Invokeメソッドから遷移を行う場合のプロファイラ通知を抑制することで、regressed profiler testを修正します。

変更内容

  • src/coreclr/vm/interpexec.cpp: インタープリタのcalli-with-transition経路で、現在解釈実行中のメソッドがP/Invokeの場合、ProfilerManagedToUnmanagedTransitionMD/ProfilerUnmanagedToManagedTransitionMDコールバックを抑制(変更: +2/-2)

パフォーマンスへの影響

影響なし(プロファイライベント報告の重複削減に伴う若干のオーバーヘッド削減が期待できますが、ランタイム性能への直接的な影響はありません)

関連Issue

#126509

その他

  • インタープリタモード時のプロファイラ動作に関する修正
  • src/tests/profiler/transitions/transitions.csrojで回帰テストを復旧
  • ILStub廃止による遷移ロジック再配置に伴う内部実装調整

#127644 Fix NativeAOT hex config parser to handle 0x/0X prefix

  • 作成者: @Copilot
  • 作成日時: 2026年05月01日 11:10:52(UTC)
  • マージ日時: 2026年05月02日 02:57:05(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

NativeAOT の環境変数パーサ(RhConfig::Environment::TryGetIntegerValue)が 16 進値の 0x/0X プレフィックスに対応していなかったため、DOTNET_GCHeapHardLimit=0xC0000000 のような設定値がパースに失敗していた問題を修正します。CoreCLR の strtoul 相当の動作に統一し、Collect_Aggressive_LargePages テストが NativeAOT で失敗する問題を解決します。

uint32_t startIndex = 0;
if (!decimal && cchResult >= 2 && buffer[0] == '0' && (buffer[1] == 'x' || buffer[1] == 'X'))
{
    startIndex = 2;
    if (startIndex == cchResult)
        return false; // プレフィックスのみでパース失敗
}
for (uint32_t i = startIndex; i < cchResult; i++)

変更内容

  • src/coreclr/nativeaot/Runtime/RhConfig.cpp — TryGetIntegerValue メソッドで、16 進パースモード時に先頭の 0x/0X プレフィックスをスキップするロジックを追加。プレフィックスのみで有効な 16 進数字がない場合は false を返す(パースエラー)。

パフォーマンスへの影響

影響なし

関連Issue

#127644 #127290(参照:テスト追加PR)

その他

  • 修正によって GCHeapHardLimit が正しくパースされるため、GCLargePages=2 設定時に GC が CLR_E_GC_LARGE_PAGE_MISSING_HARD_LIMIT エラーを返すことがなくなります。
  • CoreCLR の strtoul ベースの実装との動作統一により、16 進設定値の互換性が向上します。

#127640 Fix NativeAOT GC roots after universal transition

概要

NativeAOT GC stack walkでユニバーサルトランジション(universal transition)フレームからスタートした場合、スクラッチレジスタが不正にGCルートとして報告される問題を修正しました。フレームのアンワインド後、ActiveStackFrameをクリアすることで、管理者フレームのスクラッチレジスタがpost-call GC情報から報告されるのを防ぎます。これにより、古いスタンプ状態(コードポインタなど)がGCオブジェクトとして誤認識される問題を解決します。

変更内容

  • src/coreclr/nativeaot/Runtime/StackFrameIterator.cpp: 非EHユニバーサルトランジションスルーンスのアンワイン後にActiveStackFrameをクリア(+4行)
    • 管理フレームがスクラッチレジスタ報告の対象にならないよう制御
    • 保守的なスタック範囲の発行は維持

パフォーマンスへの影響

影響なし。ただし信頼性が大幅に向上:

  • 修正前:System.Linq.Tests NativeAOT並列ストレステスト 69実行中63成功、6回のfail-fast即座クラッシュ(失敗率8.7%)
  • 修正後:同じテストループで612.3秒間、並列度4で132実行、132成功、0クラッシュ、0テスト失敗(100%成功)

関連Issue

なし

その他

GC root検証エラーの根本原因は、スクラッチレジスタ(RAX)に格納されたコードポインタ(System.Linq.Enumerable.Iterator<int>.System.Collections.IEnumerator.get_Current)がGCオブジェクトとして誤認識されたこと。修正により、アンワイン完了までスクラッチレジスタの報告を遅延させ、保守的なスタック範囲のみを報告するようになります。


#127590 JIT: make funclet order correspond to EH clause order

概要

WebAssemblyでのEH(例外処理)サポート向けに、JITがfunclet(例外処理コード)の順序をEHクローズの順序に対応させる変更。これにより、Wasmホストがオフセットデータに依存せずにfuncletをEHクローズと関連付けることが可能になります。フィルタ付きのEHクローズの場合、フィルタfuncletは必ずcatch funcletの前に配置されます。

変更内容

  • flowgraph.cpp: fgCreateFunclets内でVM EH clause順序マッピングを計算・格納する処理を追加
  • compiler.h: 順序マッピングを保持する新規メンバーcompEHorderTabを追加(内部API)
  • codegencommon.cpp: EH報告ロジックをリファクタリング。従来は報告時にクローズをソートしていたが、事前計算されたcompEHorderTabを使用するように変更
  • fgwasm.cpp: Wasm EH virtual-IP clause構築ロジックを調整し、新しい順序マッピングに対応
  • fgbasic.cpp: fgRelocateEHRangeヘッダーのコメントを削除

パフォーマンスへの影響

影響なし。変更は計算順序の最適化であり、実行時のパフォーマンス特性は変わりません。funclet生成時に一度だけ順序を計算し、EH報告時の冗長なソート処理が削除されるため、若干の改善が期待できます。

関連Issue

なし

その他

  • 変更はJITコンパイラの内部実装に限定されており、公開APIへの影響はありません
  • Wasm固有のEH処理ロジック(fgwasm.cpp)が主な対象で、従来のプラットフォームへの影響は最小限です
  • フィルタを含むEHクローズ(2つのfuncletが生成される場合)でも、フィルタfuncletが常にcatch funcletより前に配置されるため、順序マッピングは一貫性を保ちます

目次