Pull Request on 2026年04月09日

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

注意点

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


目次

  1. #126709 [wasm][coreclr] Implement webcil V1 support in WebcilConverter and readers
  2. #126694 Fix RemoteExecutor-dependent tests failing on platforms where RemoteExecutor is unsupported
  3. #126686 Update comment for Async covariant return issue
  4. #126684 Move Thread::m_pInterpThreadContext near top of Thread class for stable asm offset
  5. #126672 Avoid const_cast in methods on PEDecoder
  6. #126666 Add watchdog instrumentation to OleTxTests.Recovery to capture hang diagnostics
  7. #126661 Disable WindowsAlternateDataStreamOverwrite test on Windows Arm64
  8. #126657 Add missing tests for resumeAt=2 path in regex expression conditional
  9. #126655 Skip Start_Disposed_ThrowsObjectDisposedException on Apple mobile platforms
  10. #126652 Add TARGET_APPLE to System.Private.CoreLib DefineConstants for Apple platforms
  11. #126648 Change DirectoryNotFoundException binary serialization constructor to use GetValueNoThrow
  12. #126640 Clarify documentation of IChangeToken.ActiveChangeCallbacks
  13. #126616 [release/9.0] Update branding to 9.0.16
  14. #126615 [release/8.0] Update branding to 8.0.27
  15. #126589 [PERF] Add wasm_coreclr and coreclr_r2r_interpreter to perf-build pipeline
  16. #126587 JIT: dominating redundant branch opt
  17. #126586 Add linux_arm64 platform to coreclr_r2r_interpreter build
  18. #126579 Fix initialization of t_MostRecentUMEntryThunkData in reverse pinvokes
  19. #126548 [release/11.0-preview3] Source code updates from dotnet/dotnet
  20. #126534 Cache version-resilient hash code on MethodTableAuxiliaryData to fix superlinear behavior with polymorphic recursion
  21. #126531 [main] Source code updates from dotnet/dotnet
  22. #126522 Use LifetimeHolder for COM interop holders
  23. #126521 Use CodeRangeMapRangeList for callcounting stubs and remove unneeded StubManagers
  24. #126493 Disable FEATURE_PGO on WebAssembly, iOS, TVOS, and MacCatalyst
  25. #126474 [NET] Add a new pipeline for PR trigger on top of the existing stress pipelines
  26. #126471 Fix race condition in cached interface dispatch stubs
  27. #126470 Fix ConfigurationBinder failing to bind empty array to constructor parameter
  28. #126466 Refactor cDac tests to use typed views
  29. #126411 Handle non-existent root directory in PhysicalFilesWatcher
  30. #126307 Close socket that leaks on connect failed
  31. #126065 Add Log10 to IBinaryInteger
  32. #126045 Move shared Linux build pool defaults from Ubuntu 22.04 to Azure Linux 3
  33. #125539 Adding EnumMethodDefinitionByName, StartEnumMethodDefinitionsByName, and EndEnumMethodDefinitionsByName cDAC APIs
  34. #125283 TarReader: implement GNU sparse format 1.0 (PAX)
  35. #125174 JIT: Share suspension epilogs in async transformation
  36. #124405 Backport XML docs for System.Diagnostics.FileVersionInfo from dotnet-api-docs
  37. #117473 Box value types implementing IXmlSerializable in XmlSerializer generated IL

#126709 [wasm][coreclr] Implement webcil V1 support in WebcilConverter and readers

  • 作成者: @radekdoulik
  • 作成日時: 2026年04月09日 14:27:27(UTC)
  • マージ日時: 2026年04月09日 21:36:52(UTC)
  • ラベル: arch-wasm area-Infrastructure-coreclr

概要

Webcil形式のバージョン1(V1)対応を実装するPRです。先行するPR #126388でWebcil共有ライブラリがバージョン0からバージョン1に更新されたため、WebcilConverter、WebcilReader、およびMonoローダーをV0/V1の両方に対応させます。V0は28バイト、V1は32バイト(TableBaseフィールド追加)のヘッダサイズに対応し、後方互換性を維持しながらV1対応を実現します。

変更内容

  • Webcil.cs: WebcilHeader構造体にTableBaseフィールド(4バイト)を追加してV1ヘッダレイアウト(32バイト)をサポート
  • WebcilConverter.cs: webcilVersionパラメータを追加して、V0(28バイト)またはV1(32バイト)ヘッダを動的に書き込み。デフォルトはV0。バージョン検証とWriteStructureの境界チェック実装
  • WebcilReader.cs: V0ヘッダ(28バイト)を先読みし、V1の場合は追加の4バイトTableBaseを条件付きで読み込み。バージョンに応じてセクションディレクトリオフセットを調整
  • webcil-loader.c(Mono): V0/V1の両方のヘッダを受け入れ、適切な境界チェックとヘッダサイズを用いたセクションオフセット計算を実装
  • WasmAppBuilder/WebcilConverter.cs: MSBuildタスクラッパーにwebcilVersionパラメータを追加

パフォーマンスへの影響

影響なし。V1ヘッダは4バイト増加するのみで、実行時パフォーマンスへの影響はありません。

関連Issue

#126388(Webcil共有バージョンの更新)
#126698(置換対象PR)

その他

  • CoreCLR browser-wasmテスト:474/476パス(スキップ2、失敗0)
  • Mono browser-wasmテスト:469/476パス(既存DateTime関連5失敗、Webcil関連失敗なし)
  • WebcilConverterのデフォルトはV0で、非R2Rビルド向け。R2R/crossgen2パス(WasmObjectWriter + WebcilEncoder)は独立してV1を生成。CoreCLRとMonoの両デコーダがV0/V1対応済み

#126694 Fix RemoteExecutor-dependent tests failing on platforms where RemoteExecutor is unsupported

  • 作成者: @Copilot
  • 作成日時: 2026年04月09日 08:05:03(UTC)
  • マージ日時: 2026年04月09日 13:20:28(UTC)
  • ラベル: area-System.Diagnostics.Process

概要

RemoteExecutorがサポートされていないプラットフォーム(NanoServer等のReadyToRun構成)において、RemoteExecutorに依存するテストがPlatformNotSupportedExceptionをスローして失敗する問題を修正しました。テストを適切にスキップするよう、条件付き実行属性で保護しました。

変更内容

  • ProcessHandlesTests.Windows.cs: 3つのテストメソッドについて、[Fact]/[Theory][ConditionalFact]/[ConditionalTheory]に変更し、RemoteExecutor.IsSupported条件で保護。using Microsoft.DotNet.XUnitExtensionsを追加。
  • ProcessStartInfoTests.cs: UserNameCantBeCombinedWithInheritedHandlesテストメソッド(CreateProcessLong()経由でRemoteExecutorに依存)に同様の修正を適用。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

この修正により、RemoteExecutorがサポートされていないプラットフォームではテストが例外をスローするのではなくスキップされるようになります。テストフレームワークの条件付き実行メカニズムを活用した内部テスト構造の改善です。


#126686 Update comment for Async covariant return issue

  • 作成者: @MichalStrehovsky
  • 作成日時: 2026年04月09日 02:29:29(UTC)
  • マージ日時: 2026年04月09日 12:56:23(UTC)
  • ラベル: area-Infrastructure

概要

非同期共変戻り値機能に関するNativeAOT対応の状況を追跡するために、テストプロジェクトのコメントを更新しました。汎用的な「NYI(Not Yet Implemented)」記述を、追跡対象の具体的なランタイムIssueへのリンクに置き換えています。

変更内容

  • src/tests/async/covariant-return/covariant-returns.csproj: NativeAOT無効化の理由に関するコメントを、#126685への直接リンクに更新

パフォーマンスへの影響

影響なし

関連Issue

#126686#126685

その他

なし


#126684 Move Thread::m_pInterpThreadContext near top of Thread class for stable asm offset

  • 作成者: @Copilot
  • 作成日時: 2026年04月09日 02:20:01(UTC)
  • マージ日時: 2026年04月09日 20:52:02(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

Thread::m_pInterpThreadContext フィールドを Thread クラスの末尾から先頭付近の安定した位置に移動させることで、ビルド構成によって変動していたアセンブリオフセットを固定化します。これにより、アーキテクチャ固有のアセンブリコード(asmconstants.h)におけるオフセット定義の変更を最小限に抑え、ビルド互換性を向上させます。

変更内容

  • src/coreclr/vm/threads.h: m_pInterpThreadContextThread クラスの先頭付近の安定したフィールドグループに移動
  • src/coreclr/vm/amd64/asmconstants.h: amd64アーキテクチャ用のオフセット定義を簡素化(-12行)
  • src/coreclr/vm/arm/asmconstants.h: ARMアーキテクチャ用のオフセット定義を簡素化(-4行)
  • src/coreclr/vm/arm64/asmconstants.h: ARM64アーキテクチャ用のオフセット定義を簡素化(-8行)
  • src/coreclr/vm/loongarch64/asmconstants.h: LoongArch64アーキテクチャ用のオフセット定義を簡素化
  • src/coreclr/vm/riscv64/asmconstants.h: RISC-V64アーキテクチャ用のオフセット定義を簡素化

パフォーマンスへの影響

影響なし(メモリレイアウト内でのフィールド位置変更のため、実行時パフォーマンスに直接的な変化はありません)

関連Issue

なし

その他

本変更は、複数のアーキテクチャ(amd64、ARM、ARM64、LoongArch64、RISC-V64)に対応するランタイム内部実装の構造変更です。公開APIには影響しません。フィールドの再配置により、アセンブリコード内でのハードコードされたオフセット値の変動を抑制し、ビルド時の脆弱性を軽減する目的です。


#126672 Avoid const_cast in methods on PEDecoder

  • 作成者: @Copilot
  • 作成日時: 2026年04月08日 22:55:38(UTC)
  • マージ日時: 2026年04月09日 22:59:36(UTC)
  • ラベル: area-VM-coreclr

概要

PEDecoder クラスの const メソッド内で使用されていた8か所の const_cast を削除し、キャッシュフィールドを mutable として宣言することで、const-correctness を改善します。動作やメモリレイアウトに変更はなく、コンパイル時の型安全性向上のみです。

変更内容

  • src/coreclr/inc/pedecoder.hm_flagsm_pNTHeadersm_pCorHeaderm_pReadyToRunHeader の4つのキャッシュフィールドを mutable として宣言
  • src/coreclr/utilcode/pedecoder.cppHasNTHeadersCheckNTHeadersCheckCorHeaderCheckILOnly(2箇所)、FindReadyToRunHeader(2箇所)で計7か所の const_cast を削除
  • src/coreclr/inc/pedecoder.inlGetCorHeader メソッド内の1か所の const_cast を削除

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

これはコード品質改善施策です。mutable キーワードは C++ の標準的な手法で、const メソッド内でのメンバ変数の変更が意図的かつ明示的であることを示します。ランタイム動作に変更はありません。


#126666 Add watchdog instrumentation to OleTxTests.Recovery to capture hang diagnostics

  • 作成者: @danmoseley
  • 作成日時: 2026年04月08日 22:06:19(UTC)
  • マージ日時: 2026年04月09日 15:40:40(UTC)
  • ラベル: area-CodeGen-coreclr

概要

OleTxTests.RecoveryがMSDTC待機時にインターミッテントにハング(20分以上)する問題に対処するため、スキップ属性を削除し、5分のタイムアウト後にEnvironment.FailFastを実行するウォッチドッグスレッドを追加します。これにより、通常のCoreCLR実行時の失敗を検出しつつ、ハング診断用のクラッシュダンプを取得できます。

var testCompleted = new ManualResetEventSlim(false);
var watchdog = new Thread(() =>
{
    if (!testCompleted.Wait(TimeSpan.FromMinutes(5)))
        Environment.FailFast("OleTxTests.Recovery did not complete within 5 minutes");
});
watchdog.IsBackground = true;
watchdog.Start();

try { /* test code */ }
finally { testCompleted.Set(); }

変更内容

  • src/libraries/System.Transactions.Local/tests/OleTxTests.cs: [SkipOnCoreClr]属性を削除し、ウォッチドッグスレッド機構を追加。バックグラウンドスレッドが5分間テスト完了を待機し、タイムアウト時にEnvironment.FailFastを実行してクラッシュダンプを生成します。完了シグナルはfinallyブロック内で設定されるため、通常のテスト実行に干渉しません。

パフォーマンスへの影響

影響なし。ウォッチドッグスレッドはバックグラウンドスレッドであり、正常系のテスト実行パスに追加のオーバーヘッドはありません。

関連Issue

#126304

その他

本PR は内部テストコード(System.Transactions.Localテストスイート)の変更であり、公開APIへの影響はありません。ウォッチドッグ機構は根本原因の調査のための診断支援を目的とした暫定的な対応です。


#126661 Disable WindowsAlternateDataStreamOverwrite test on Windows Arm64

  • 作成者: @Copilot
  • 作成日時: 2026年04月08日 21:07:19(UTC)
  • マージ日時: 2026年04月09日 06:21:39(UTC)
  • ラベル: area-System.IO

概要

Windows Arm64環境でWindowsAlternateDataStreamOverwriteテストが断続的にCopyFileExからERROR_INVALID_PARAMETERエラーで失敗する問題に対応します。[ActiveIssue]属性を使用してWindows Arm64プラットフォーム上でのみテストをスキップし、他のプラットフォームではテスト実行を継続します。

変更内容

  • src/libraries/System.Runtime/tests/System.IO.FileSystem.Tests/File/Copy.cs
    • WindowsAlternateDataStreamOverwriteテストメソッドに[ActiveIssue]属性を追加
    • スキップ条件: PlatformDetection.IsWindows && PlatformDetection.IsArm64Process
    • このテストメソッドはFile_Copy_str_str_bおよびFileInfo_CopyTo_str_bに影響(後者は前者を継承)

パフォーマンスへの影響

影響なし

関連Issue

#83659

その他

  • テスト関連の変更(System.IO.FileSystem.Tests)
  • Windows Arm64上での代替データストリーム機能は、他のテストケース(L220の関連コード)で引き続きカバーされる
  • 破壊的変更や互換性への影響なし

#126657 Add missing tests for resumeAt=2 path in regex expression conditional

  • 作成者: @Copilot
  • 作成日時: 2026年04月08日 19:04:42(UTC)
  • マージ日時: 2026年04月09日 15:36:24(UTC)
  • ラベル: area-System.Text.RegularExpressions

概要

正規表現コンパイラのresumeAt=2パス(ループ内のyes-onlyな式条件)に対するテストカバレッジを追加しました。PR #126561の修正に関連して、コードレビューワークフローで特定されたテストの欠落部分を補完します。

変更内容

  • Regex.MultipleMatches.Tests.cs: Matches_TestData()に3つの新しいテストケースを追加
    • Pass-through path(条件失敗時): (?((?'-1'))(?'1'.)+)+(?!(?'-1'))パターンで、ループ内の各位置で空マッチを生成(#if !NETFRAMEWORKで条件付け。.NET Frameworkの空マッチセマンティクスの違いに対応)
    • Yes-branch取得(偶数入力): ((?'1'.)(?((?'-1'))(?'1'.)))+パターンで"abcd"を検証
    • Yes-branch取得(奇数入力): 同パターンで"abc"による部分マッチ動作を検証

後者2つのケースは、非バックトラッキングなyes-branchのためisInLoopトリガーが必須となり、resumeAt=2の主要なカバレッジとなります(従来のpostYesDoneLabel != originalDoneLabel条件ではfalseになるケース)。

パフォーマンスへの影響

影響なし

関連Issue

#126561

その他

  • 既存の32,100テストは全て継続して合格
  • テストケース1は.NET Frameworkとの空マッチセマンティクスの相違により条件付けされている
  • テストケース2・3はクロスターゲット対応

#126655 Skip Start_Disposed_ThrowsObjectDisposedException on Apple mobile platforms

  • 作成者: @steveisok
  • 作成日時: 2026年04月08日 18:56:38(UTC)
  • マージ日時: 2026年04月09日 18:48:32(UTC)
  • ラベル: area-System.Diagnostics.Process

概要

Apple モバイルプラットフォーム(iOS/tvOS/MacCatalyst)において、Process.Start() がプロセス起動前に PlatformNotSupportedException をスローするため、Start_Disposed_ThrowsObjectDisposedException テストをスキップするようにしました。このテストは処理済みオブジェクトの場合に ObjectDisposedException の発生を期待していますが、プラットフォーム非対応エラーが先に発生するため、runtime-extra-platforms ビルドで確定的な失敗が発生していました。

変更内容

  • src/libraries/System.Diagnostics.Process/tests/ProcessTests.cs: Start_Disposed_ThrowsObjectDisposedException テストメソッドに [SkipOnPlatform(TestPlatforms.iOS | TestPlatforms.tvOS | TestPlatforms.MacCatalyst)] 属性を追加

パフォーマンスへの影響

影響なし

関連Issue

#126654

その他

このテストスキップはAppleモバイルプラットフォーム上での既存の設計制限に対応するもので、同一ファイル内の20以上の他のテストで既に使用されている [SkipOnPlatform] パターンに従っています。テスト失敗は7つのビルドレグで確定的に発生していました。


#126652 Add TARGET_APPLE to System.Private.CoreLib DefineConstants for Apple platforms

  • 作成者: @Copilot
  • 作成日時: 2026年04月08日 18:21:12(UTC)
  • マージ日時: 2026年04月09日 01:43:41(UTC)
  • ラベル: area-System.Runtime.InteropServices

概要

Apple プラットフォーム上で ILLink により Swift 相互運用型(SwiftSelfSwiftErrorSwiftIndirectResult)が System.Private.CoreLib から不正にトリミングされる問題を修正します。CreateRuntimeRootILLinkDescriptorFile タスクが corelib.h を処理する際に TARGET_APPLE が定義されていなかったため、Swift 型の保護ルートが生成されず、実行時に TypeLoadException が発生していました。System.Private.CoreLib の MSBuild DefineConstantsTARGET_APPLE を追加することで、Apple プラットフォーム向けビルド時に Swift 型定義が ILLink ディスクリプタに正しく含まれるようになります。

変更内容

  • src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems: IsApplePlatformtrue の場合、DefineConstantsTARGET_APPLE を追加

パフォーマンスへの影響

影響なし

関連Issue

#126557

その他

  • この修正は内部実装(MSBuild 設定)の変更であり、公開API には影響しません
  • tvOS arm64 を含む Apple プラットフォーム向けのコンパイル時の問題の修正です
  • ILLink ディスクリプタ生成プロセスにおいて、C# のプリプロセッサ定義と C++ ヘッダの #ifdef ブロックの整合性を確保する重要な修正です

#126648 Change DirectoryNotFoundException binary serialization constructor to use GetValueNoThrow

  • 作成者: @Copilot
  • 作成日時: 2026年04月08日 14:46:44(UTC)
  • マージ日時: 2026年04月09日 01:25:36(UTC)
  • ラベル: area-System.IO

概要

DirectoryNotFoundExceptionの逆シリアライズコンストラクタを変更し、SerializationInfoエントリを線形スキャンするforeachループをGetValueNoThrowによる直接参照に置き換えました。これにより、他の例外クラスのパターンに合わせてコードの効率化と統一化を実現します。

変更内容

  • src/libraries/System.Private.CoreLib/src/System/IO/DirectoryNotFoundException.cs
    • foreach (SerializationEntry ...)によるオプショナルフィールドDirectoryPathの線形スキャンを削除
    • SerializationInfo.GetValueNoThrowによる直接参照に変更(-8/+1行)

パフォーマンスへの影響

改善あり:逆シリアライズ時にSerializationInfoエントリのコレクション全体をスキャンする必要がなくなり、O(n)の処理がO(1)の直接参照に最適化されます。ただし、DirectoryNotFoundExceptionの逆シリアライズは通常頻度が低いため、実測への影響は限定的と考えられます。

関連Issue

なし

その他

  • CoreLib内の他の例外クラスと一貫した実装パターンへの統一化
  • 破壊的変更や互換性への影響はなし(内部実装の最適化のみ)

#126640 Clarify documentation of IChangeToken.ActiveChangeCallbacks

  • 作成者: @svick
  • 作成日時: 2026年04月08日 11:59:55(UTC)
  • マージ日時: 2026年04月09日 08:56:01(UTC)
  • ラベル: area-Extensions-Primitives

概要

IChangeToken.ActiveChangeCallbacksプロパティのドキュメンテーションを明確化するPRです。特にCompositeChangeTokenのような複合トークンにおいて、ActiveChangeCallbacks == trueすべての基盤となる変更が確実にコールバックをトリガーすることを意味しないというケースを正確に説明するようにドキュメントを改善しています。

変更内容

  • IChangeToken.cs: ActiveChangeCallbacksプロパティのXMLドキュメントを改訂し、コンシューマーの期待値精度に関する注釈を追加
  • CompositeChangeToken.cs: CompositeChangeTokenのコールバック伝播動作を文書化し、内部トークンがアクティブなコールバックを持つ/持たないことがコンポジットのActiveChangeCallbacksの意味にどう影響するかを明確化

パフォーマンスへの影響

影響なし

関連Issue

#40677

その他

  • この変更はMicrosoft.Extensions.Primitivesライブラリ内のパブリックAPIドキュメンテーションの改善であり、実装ロジックの変更はありません
  • 内部実装ではなくドキュメンテーション(XMLコメント)のみの更新となります

#126616 [release/9.0] Update branding to 9.0.16

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年04月07日 20:28:40(UTC)
  • マージ日時: 2026年04月09日 22:18:58(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

.NET 9.0ランタイムのパッチバージョンを9.0.15から9.0.16へ更新するブランディング変更です。release/9.0ブランチのバージョンプロパティを更新しています。

変更内容

  • eng/Versions.props: ProductVersionとPatchVersionを更新
    • PatchVersion: 15 → 16
    • ProductVersion: 9.0.15 → 9.0.16

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

なし


#126615 [release/8.0] Update branding to 8.0.27

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年04月07日 20:26:55(UTC)
  • マージ日時: 2026年04月09日 22:32:35(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

.NET 8.0のサービシング版バージョンを8.0.26から8.0.27へ更新するためのバージョン情報更新です。release/8.0ブランチのブランディング情報を次のパッチリリースに合わせて整備しています。

変更内容

  • eng/Versions.props: ProductVersionPatchVersionをそれぞれ8.0.268.0.272627に更新(+2行、-2行)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

なし


#126589 [PERF] Add wasm_coreclr and coreclr_r2r_interpreter to perf-build pipeline

  • 作成者: @LoopedBard3
  • 作成日時: 2026年04月06日 21:45:25(UTC)
  • マージ日時: 2026年04月09日 19:37:45(UTC)
  • ラベル: area-Infrastructure-coreclr perf-pipeline

概要

perf-build パイプラインに wasm_coreclrcoreclr_r2r_interpreter の2つの新しいビルドタイプを追加し、every-commit perf ビルドパイプラインに含めることで、これらがビルドキャッシュシステム(BCS)に登録、ビルド、アップロードされるようにします。

変更内容

  • eng/pipelines/performance/perf-build.yml
    • wasm_coreclrcorellr_r2r_interpreter ビルドを有効/無効にするためのパイプラインパラメータを追加
    • これらのビルドタイプを RegisterBuildBuildUploadArtifacts ステージテンプレート呼び出しに追加

パフォーマンスへの影響

パイプライン構成の変更であり、実行時のパフォーマンスへの直接的な影響なし。ただし、ビルドパイプラインの実行時間が増加する可能性があります。

関連Issue

なし

その他


#126587 JIT: dominating redundant branch opt

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年04月06日 20:48:24(UTC)
  • マージ日時: 2026年04月09日 16:29:03(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラに、支配的なブランチ(外側の条件分岐)が支配されるブランチ(内側の条件分岐)の述語に含意される場合に、支配的なブランチを最適化して削除する機能を追加しました。例えば、if (x > 0) if (x > 1) S(); では外側の if (x > 0) を削除できます。

// 最適化前
if (x > 0)
    if (x > 1)
        S();

// 最適化後(外側の条件は不要)
if (x > 1)
    S();

変更内容

  • redundantbranchopts.cpp: 新しい optRedundantDominatingBranch メソッドを実装し、支配的な条件分岐が支配されるブランチの比較によって含意される場合に定数畳み込みを行うロジックを追加
  • block.h/block.cpp: 支配されるブロックを投機的に実行しても安全かどうかを判定するための BasicBlock::hasSideEffects() ヘルパーメソッドを追加
  • compiler.h: 新しいオプティマイザーのエントリーポイントを宣言
  • テストファイル: 支配的なブランチの削除パターンをカバーするリグレッションテストを追加

パフォーマンスへの影響

特定のネストされたif文パターンにおいて、不要な条件分岐を削除することでコード品質を向上させます。具体的なベンチマーク数値は提供されていません。

関連Issue

#126554

その他

この最適化はRBO(Redundant Branch Optimization)フェーズの一部として機能します。支配されるブロックに副作用がない場合にのみ、支配的なブランチの削除が安全に行われます。


#126586 Add linux_arm64 platform to coreclr_r2r_interpreter build

  • 作成者: @DrewScoggins
  • 作成日時: 2026年04月06日 20:42:31(UTC)
  • マージ日時: 2026年04月09日 15:55:59(UTC)
  • ラベル: area-Infrastructure-coreclr perf-pipeline

概要

CoreCLR composite R2R-with-interpreter-fallback ビルドに linux_arm64 プラットフォームを追加し、arm64 Cobalt パフォーマンス実行が linux_x64 と同じビルド成果物を利用できるようにします。

変更内容

  • eng/pipelines/performance/templates/perf-coreclr-build-jobs.yml: coreclr_r2r_interpreter ビルドジョブのプラットフォームマトリックスに linux_arm64 を追加

パフォーマンスへの影響

影響なし(ビルドパイプライン設定の変更であり、ランタイム実行性能への直接的な影響はありません)

関連Issue

なし

その他

この変更により、arm64 Cobalt パフォーマンス測定が既存の linux_x64 ビルドと同じ構成(composite R2R + interpreter フォールバック)でのテストが可能になります。


#126579 Fix initialization of t_MostRecentUMEntryThunkData in reverse pinvokes

  • 作成者: @BrzVlad
  • 作成日時: 2026年04月06日 16:41:29(UTC)
  • マージ日時: 2026年04月09日 04:58:37(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

リバースP/Invokeにおいて、インタープリタがUMEntryThunkDataをTLS(スレッドローカルストレージ)変数経由で受け取る際の初期化が失敗していた問題を修正しました。前回のコミット(60f1dc1b)でエントリーポイントの最適化により、プレスタブをスキップしてインタープリタプリコードを直接呼び出すようになったため、必要なTLS変数の設定が漏れていました。

変更内容

  • src/coreclr/vm/dllimportcallback.cpp: リバースP/Invokeがインタープリタプリコードをスキップするケースで、TLS変数t_MostRecentUMEntryThunkDataを適切に初期化するロジックを追加(+8/-4)
  • src/coreclr/vm/comcallablewrapper.cpp: COM呼び出し可能ラッパー内の不要なインタープリタ関連コードを削除(+2/-10)
  • 変数名targetIsPrecodecanSkipPreStubに改名し、コードの意図をより明確化

パフォーマンスへの影響

影響なし。本修正はバグ修正であり、パフォーマンス特性の変化を伴いません。

関連Issue

なし

その他

本修正はリバースP/Invokeを通じてインタープリタモードで実行される.NETメソッドに対してのみ影響します。内部実装(ランタイムのプレスタブとTLS管理)の修正であり、公開APIの変更はありません。


#126548 [release/11.0-preview3] Source code updates from dotnet/dotnet

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年04月04日 18:02:57(UTC)
  • マージ日時: 2026年04月09日 11:14:20(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet/dotnetリポジトリからのコードフロー更新です。release/11.0-preview3ブランチへ、2026年4月8日時点のソースコード変更と依存関係の更新を取り込みます。主にコンパイラ、ビルドツール、NuGetツール、ランタイム関連の依存パッケージが更新されています。

変更内容

  • eng/Version.Details.props: バージョン設定の更新(+39/-39行)
  • eng/Version.Details.xml: 依存関係バージョンの詳細記述更新(+79/-79行)
  • global.json: グローバル設定ファイルの更新(+4/-4行)

更新された主な依存パッケージ

  • Microsoft.CodeAnalysis関連: 5.7.0-1.26202.110 → 5.7.0-1.26207.106
  • Microsoft.DotNet.Arcade.Sdk等ビルドツール: 11.0.0-beta.26202.110 → 11.0.0-beta.26207.106
  • Microsoft.NETCore.App.Ref、System.Reflection.Metadata、System.Text.Json等: 11.0.0-preview.3.26202.110 → 11.0.0-preview.3.26207.106
  • NuGet.Frameworks/Packaging/ProjectModel/Versioning: 7.6.0-rc.20310 → 7.6.0-rc.20806
  • System.CommandLine: 3.0.0-preview.3.26202.110 → 3.0.0-preview.3.26207.106

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このはマエストロによる自動コードフロー更新です。dotnet/msbuild、nuget/nuget.client、dotnet/razor、dotnet/runtime、dotnet/sdk、dotnet/winformsからの関連変更も含まれています。


#126534 Cache version-resilient hash code on MethodTableAuxiliaryData to fix superlinear behavior with polymorphic recursion

  • 作成者: @Copilot
  • 作成日時: 2026年04月04日 04:47:29(UTC)
  • マージ日時: 2026年04月09日 21:29:50(UTC)
  • ラベル: area-VM-coreclr

概要

GetVersionResilientTypeHashCodeがメモ化なしで再帰的にハッシュコードを再計算していたため、多態的再帰を含むシナリオで指数関数的なパフォーマンス低下が発生していました。本修正ではMethodTableAuxiliaryDataにキャッシュフィールドを追加し、ハッシュコードの計算結果を1度だけ保存することで、重複計算を排除します。

変更内容

  • src/coreclr/vm/methodtable.h: MethodTableAuxiliaryDataint m_cachedVersionResilientHashCodeフィールドを追加。64ビット環境での既存アライメントパディングを活用するため、構造体サイズは変わらず。
  • src/coreclr/vm/versionresilienthashcode.cpp: 配列型の早期リターン分岐を削除し、配列型と非配列型の両方を統一されたキャッシュロジックで処理。キャッシュ値が0の型(ハッシュ値が正確に0の場合)はキャッシュされない仕様。
  • src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.CoreCLR.cs: MethodTableAuxiliaryDataのマネージドミラー構造体にキャッシュフィールドを追加。32ビット環境でのメモリレイアウト破損を防止するため必須。

パフォーマンスへの影響

大幅な改善が確認されています。

多態的再帰ベンチマーク結果(修正前後の比較):

n値 修正前 修正後
16 16 ms 4 ms
20 93 ms 4 ms
24 555 ms 4 ms
28 3,716 ms 4 ms
31 ~15秒 4 ms

修正後は各深さで初回インスタンス化後に定時間化。メモリ影響は64ビット環境で0バイト(既存パディング領域を再利用)、32ビット環境で4バイト(33%増)。

関連Issue

#126534

その他

  • キャッシュは遅延初期化され、値0は「未設定」を示す。ハッシュコード値が正確に0になる型は稀であるため、センチネル値衝突の影響は無視できるレベル。
  • 既存のジェネリックハッシュアルゴリズムは高品質で、衝突なし。指数関数的な性能問題は純粋にメモ化の欠落に起因していた。
  • 32ビット環境での互換性: マネージドミラー構造体の更新が必須。更新なしではメモリレイアウトが破損し、フィールドアクセスが正しく機能しません(ランタイムの内部実装に影響)。

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年04月04日 02:08:16(UTC)
  • マージ日時: 2026年04月09日 08:06:35(UTC)
  • ラベル: area-codeflow

概要

VMR(Virtual Monorepo)からのコードフロー更新です。複数の.NET関連リポジトリ(ASP.NET Core、EF Core、Roslyn、MSBuild、NuGetなど)から最新の変更をマージし、依存関係パッケージを更新しています。2026年4月4日時点のビルド309188が適用されています。

変更内容

  • eng/Version.Details.props: バージョン情報の更新(+39/-39行)
  • eng/Version.Details.xml: 依存関係の詳細バージョン定義の更新(+79/-79行)
  • global.json: グローバル設定の更新(+4/-4行)

更新された主要な依存関係パッケージ:

  • Microsoft.CodeAnalysis系: 5.7.0-1.26201.113 → 5.7.0-1.26203.108
  • Microsoft.DotNet.Arcade.Sdk他ビルドツール: 11.0.0-beta.26201.113 → 11.0.0-beta.26203.108
  • Microsoft.NETCore関連(Ref、ILAsm等): 11.0.0-preview.4.26201.113 → 11.0.0-preview.4.26203.108
  • NuGet.Framework/Packaging/ProjectModel: 7.6.0-rc.20213 → 7.6.0-rc.20408
  • System.Text.Json他システムライブラリ: プレビュー版に更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRは自動化されたコードフロー更新(dotnet-maestro[bot]により作成)です
  • aspnetcore、command-line-api、efcore、emsdk、msbuild、nuget.client、roslyn、runtimeの各リポジトリからの変更が含まれています
  • darc コマンドで詳細なdiffを確認可能です

#126522 Use LifetimeHolder for COM interop holders

  • 作成者: @AaronRobinsonMSFT
  • 作成日時: 2026年04月03日 23:14:16(UTC)
  • マージ日時: 2026年04月09日 00:04:31(UTC)
  • ラベル: area-VM-coreclr

概要

CoreCLR VM/COM相互運用のリソース管理を標準化するため、従来のWrapper<...>ベースのRAIIホルダーを新しいLifetimeHolderReleaseHolderSpecializedWrapper抽象化に統一するリファクタリング。COM相互運用、GC/オブジェクトハンドル、CLRConfig文字列バッファ、ローダー/リソースヘルパーなどの複数の領域で、ボイラープレートコードを削減しながら動作を保持します。

変更内容

  • ホルダー型の統一化: OBJECTHANDLEHolderPEImageHolderCLRConfigStringHolderCRITSEC_AllocationHolderなどをLifetimeHolderトレイト基盤のタイプエイリアスに変換
  • 所有権譲渡の標準化: Extract()/SuppressRelease()パターンからDetach()への統一
  • レガシーヘルパーの削除: 不要な"DoNothing"ヘルパー関数とインラインホルダーラッパーを削除(holder.hwrappers.h、VM各ヘッダーから)
  • COM相互運用領域: NewRCWHolderSpecializedWrapperエイリアスに、CtxEntryHolderReleaseHolderベースの局所エイリアスに変換
  • VARIANT/SAFEARRAY管理: COM関連型をLifetimeHolderトレイト基盤に移行
  • LifetimeHolderの強化: operator&アサーション(空でないホルダーのアドレス取得を禁止)とoperator->を追加

パフォーマンスへの影響

影響なし。リファクタリングは動作を保持し、コンパイルされたコードのセマンティクスに変更なし。

関連Issue

なし

その他

  • 動作保持を確認するため、ローカルで検証済み
  • 40ファイルに及ぶ変更により、CoreCLRホルダーインフラストラクチャ全体の一貫性向上
  • NativeAOT領域の前方宣言からRCOBJECTHANDLEHolder削除(不要な宣言のクリーンアップ)
  • LifetimeHolderoperator&アサーション追加により、非空ホルダーへの不適切なアドレス取得を検出時点で防止

#126521 Use CodeRangeMapRangeList for callcounting stubs and remove unneeded StubManagers

  • 作成者: @rcj1
  • 作成日時: 2026年04月03日 22:38:47(UTC)
  • マージ日時: 2026年04月09日 14:32:55(UTC)
  • ラベル: area-VM-coreclr area-Diagnostics-cdac

概要

Call Counting Stubsの追跡メカニズムをCodeRangeMapRangeListに移行し、RangeSectionMapから直接Stub種別を識別できるようにしました。これにより、Call Counting Stub Allocatorの反復走査が不要になり、cDACでの効率的な検索が可能になります。同時に、Call Counting Stub Heapの明示的なEnumMemを削除し、他のCodeRangeMapRangeListユーザーと同じ列挙動作に統一しました。

変更内容

  • src/coreclr/vm/callcounting.cpp/h: RangeListからCodeRangeMapRangeListへの切り替え。古いStub範囲チェックとDAC Heap範囲列挙ロジックを削除(-160行)
  • src/coreclr/vm/stubmgr.cpp/h: RangeSectionStubManagerを通じてCall Counting Stubsを認識し、トレーシング/名前解決を転送。StubManager内の冗長な処理を削除(-63行)
  • src/coreclr/vm/codeman.h: 新しいStub種別STUB_CODE_BLOCK_CALLCOUNTINGを追加し、RangeSection報告用のStub種別文字列マッピングを導入
  • src/coreclr/vm/loaderallocator.hpp/common.h: ヘッダ依存関係を削除し、CallCountingManagerのフォワード宣言とcallcounting.hの可視性を調整
  • src/coreclr/debug/daccess/daccess.cpp、inc/dacvars.h、inc/vptr_list.h、vm/appdomain.cpp: 不要な参照や宣言を削除

パフォーマンスへの影響

Call Counting Stubの種別判定が反復走査から直接ルックアップに変更されるため、アドレス判定の性能が向上します。メモリフットプリントはHeap列挙ロジックの削除により削減されます。

関連Issue

#126521

その他

この変更はDebug/cDAC機能に関連し、Runtime内部実装の改善です。公開APIへの影響はありません。


#126493 Disable FEATURE_PGO on WebAssembly, iOS, TVOS, and MacCatalyst

  • 作成者: @Copilot
  • 作成日時: 2026年04月02日 23:24:38(UTC)
  • マージ日時: 2026年04月09日 20:49:06(UTC)
  • ラベル: area-Infrastructure

概要

PGO(Profile Guided Optimization)インフラストラクチャをWebAssembly、iOS、tvOS、MacCatalystプラットフォームで無効化し、FEATURE_DYNAMIC_CODE_COMPILEDフィーチャゲート下に移行する変更です。これらのプラットフォームではPGOが意味をなさないため、不必要なコード生成を削減し、ビルドサイズを最適化することを目的としています。

変更内容

  • clrfeatures.cmake: FEATURE_PGOFEATURE_DYNAMIC_CODE_COMPILEDブロック内に移動。指定プラットフォームではFEATURE_DYNAMIC_CODE_COMPILEDが設定されないため、自動的にPGOが除外される
  • clrdefinitions.cmake: add_compile_definitions(FEATURE_PGO)を条件付きに変更(従来は無条件)
  • pgo.cpp: !FEATURE_PGO時のスタブ実装を更新。getPgoInstrumentationResultsCreatePgoManagerのシグネチャを修正し、getPgoInstrumentationResultsFromR2RFormatの欠落スタブを追加
  • pgo.h: getPgoInstrumentationResults宣言のパラメータ名タイポ修正(pAllocatedDatapAllocatedDatapAllocatedData
  • jitinterface.cpp: getPgoInstrumentationResults内のTieredPGO()呼び出しを#ifdef FEATURE_PGOでガード
  • tieredcompilation.cpp: Tier0最適化パスのPGO計測ロジックを#ifdef FEATURE_PGOでガード
  • jithelpers.h: 10個のPGOプロファイリングJITヘルパーテーブルエントリを#ifdef FEATURE_PGOでガード、非PGOビルド時はNULLを設定
  • jithelpers.cpp: PGOプロファイリングJITヘルパー実装を#ifdef FEATURE_PGOでラップ

パフォーマンスへの影響

  • WebAssembly、iOS、tvOS、MacCatalystプラットフォームのビルドサイズが削減される(不必要なPGO関連コードが除外)
  • これらのプラットフォームではPGO計測によるオーバーヘッドが完全に排除される
  • 他のプラットフォームでのパフォーマンスへの影響は無し

関連Issue

なし

その他

  • 内部実装への変更: すべての変更はコンパイラ/ランタイムの内部実装に限定され、公開APIへの影響なし
  • 互換性: FEATURE_PGOが無効な場合のコンパイル互換性が向上(スタブ実装の完成度向上)
  • アウトパラメータ初期化: !FEATURE_PGOスタブで出力パラメータを適切に初期化し、未初期化値による潜在的なバグを防止

#126474 [NET] Add a new pipeline for PR trigger on top of the existing stress pipelines

  • 作成者: @ManickaP
  • 作成日時: 2026年04月02日 15:18:23(UTC)
  • マージ日時: 2026年04月09日 07:41:13(UTC)
  • ラベル: area-Infrastructure-libraries

概要

HTTP/SSL ストレステストパイプラインの PR トリガーをファイルパスフィルタとともに独立したパイプラインに分離する変更です。これにより、azp run ... コマンドでの手動実行が正常に機能するようになり、HTTP/SSL 製品コードの変更に対するストレステストの手動実行が可能になります。

変更内容

  • http-stages.yml / ssl-stages.yml: 既存パイプラインのステージ定義を抽出した新しい共有テンプレートファイルを作成
  • http.yml / ssl.yml: PR トリガーを削除し、スケジュール実行(夜間)のみに変更。新しいステージテンプレートを参照するよう修正
  • http-pr.yml / ssl-pr.yml: ファイルパスフィルタ付き PR トリガーを含む新しいパイプラインを作成。共有ステージテンプレートを再利用

パフォーマンスへの影響

影響なし

関連Issue

#126358 のフォローアップ(前回の試みが機能しなかった)

その他

  • このパイプラインの作成と有効化には、エンジニアリングサービスチームの支援が必要です
  • 変更は Azure Pipelines の YAML 設定ファイルのみで、ランタイムコードへの変更はありません
  • 内部インフラストラクチャに関連する変更です

#126471 Fix race condition in cached interface dispatch stubs

  • 作成者: @MichalStrehovsky
  • 作成日時: 2026年04月02日 13:49:13(UTC)
  • マージ日時: 2026年04月09日 03:59:35(UTC)
  • ラベル: area-VM-coreclr

概要

キャッシュされたインターフェイスディスパッチスタブにおけるレース条件を修正します。ディスパッチセルのm_pStubm_pCacheが原子的に更新されていても、呼び出し元とスタブによる非原子的な読み取りにより、キャッシュ成長時にレース条件が発生し、スタブが陳旧したm_pCacheを読み取ってキャッシュサイズが一致せず、マッピングされていないメモリへのアクセスが発生する可能性がありました。

RhpInterfaceDispatchNスタブに検証ロジックを追加し、m_pCacheロード後に下位2ビットがゼロであることとm_cEntriesが予想されるエントリ数と一致することを確認。不一致の場合は間接セルを通じて再ディスパッチして、現在のスタブとキャッシュペアで再試行します。

変更内容

  • amd64/arm64/arm/i386/loongarch64/riscv64 StubDispatch: RhpInterfaceDispatchNスタブにキャッシュポインタ検証(下位ビットマスク)とm_cEntriesサイズチェック、不一致時の再ディスパッチロジックを追加
  • CoreCLR amd64/arm64 CachedInterfaceDispatchCoreCLR: RhpVTableOffsetDispatchスタブに同様の検証とリトライロジックを追加
  • asmconstants.h (amd64/arm64): m_cEntriesオフセットとIDC_CACHE_POINTER_MASK定数を新規定義

パフォーマンスへの影響

キャッシュヒット時は追加検証による軽微なオーバーヘッド(ビット確認とメモリ読み取り1回)が発生します。レース条件検出時は再ディスパッチが行われるため、その分の遅延が増加しますが、これは異常系の処理です。通常動作時への著しい性能低下は見られない想定ですが、ベンチマーク結果の記載なし。

関連Issue

#121632

その他

  • Draft段階で追加の検証を予定中
  • 複数アーキテクチャ(amd64、arm64、arm、i386、loongarch64、riscv64)での対応
  • CoreCLRと汎用ランタイムの両方のディスパッチスタブを修正
  • 内部実装の修正(アセンブリレベルの最適化)であり、公開APIへの影響なし

#126470 Fix ConfigurationBinder failing to bind empty array to constructor parameter

  • 作成者: @svick
  • 作成日時: 2026年04月02日 13:37:50(UTC)
  • マージ日時: 2026年04月09日 11:57:27(UTC)
  • ラベル: area-Extensions-Configuration

概要

ConfigurationBinderが空のJSON配列([])をコンストラクタパラメータ(string[]型など)にバインドする際にArgumentExceptionをスローしていた問題を修正しました。

根本原因: BindParameterBindingPointを初期化する際に、設定セクションの文字列値("")を渡していたため、空コレクション生成の処理パスがスキップされていました。

修正内容: BindParameterBindingPointコンストラクタのinitialValue引数を削除し、デフォルト値のnullを使用するようにしました。これにより、プロパティバインディングと同様に空コレクション処理パスが正常に動作します。

変更内容

  • ConfigurationBinder.cs: BindParameter内でBindingPointを初期値なしで初期化するように変更(BindingPointinitialValue引数を削除)
  • ConfigurationBinderTests.TestClasses.cs: オプショナルな配列型コンストラクタパラメータを持つテスト用ヘルパークラスを追加
  • ConfigurationBinderTests.cs: 空配列をコンストラクタパラメータにバインドするシナリオを検証する回帰テストTestBindingEmptyArrayToConstructorParameterを追加

パフォーマンスへの影響

影響なし

関連Issue

#126312

その他

Copilotのレビューコメントで、BindParameter内のローカル変数名propertyBindingPointがコンストラクタパラメータバインディングを表しているため、parameterBindingPointなどへの改名が可読性向上につながる可能性が指摘されています。


#126466 Refactor cDac tests to use typed views

  • 作成者: @noahfalk
  • 作成日時: 2026年04月02日 12:12:58(UTC)
  • マージ日時: 2026年04月09日 10:10:13(UTC)
  • ラベル: area-Diagnostics-cdac

概要

cDAC管理単体テストを、生ポインタ/オフセット演算を削減し、型付きビュー(TypedView)を導入して可読性を向上させるようにリファクタリングしました。また、ランタイム型モックをテスト外での再利用を想定して分離構成しています。

変更内容

  • 新しい基盤インフラストラクチャ

    • LayoutSequentialLayoutBuilderプリミティブを追加し、メモリフラグメント上での名前付きプロパティアクセスを実現
    • TypedView抽象クラスを導入し、レイアウトベースのフィールド読み書き機能を提供
    • MockMemorySpaceBorrowAddressRangeMemoryを追加
  • モックデスクリプタの再構成

    • MockDescriptors.csの レガシーTypeFieldsベース機構を削除
    • SyncBlock、RuntimeFunction、ReJIT、Object、Loader、HashMap、CodeVersions、Thread等の各モックを型付きビュー+ビルダーパターンに置き換え
    • サブシステム固有のビルダー(MockSyncBlockBuilderMockLoaderBuilder等)を導入
  • テストの現代化

    • 契約作成ヘルパー関数を追加し、テストの初期化ロジックを簡潔化
    • ポインタ演算と手動メモリアクセスをビルダー経由の型付きアクセスに移行
    • TargetTestHelpers.CreateTypeInfo(Layout)メソッドを追加してレイアウト→Target.TypeInfoの変換をサポート
    • README.mdで推奨テストパターンと型付きビュー/ビルダー利用法を文書化

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 本変更は#126025で確認されたパターンを拡張
  • 全テストは従来通りパスし、テスト検証ロジックは保持
  • 製品コード(プロダクトコード)に変更なし
  • さらなるリファクタリングの余地があるが、進捗を先に取り込む方針

#126411 Handle non-existent root directory in PhysicalFilesWatcher

  • 作成者: @svick
  • 作成日時: 2026年04月01日 15:09:24(UTC)
  • マージ日時: 2026年04月09日 13:15:09(UTC)
  • ラベル: area-Extensions-FileSystem

概要

PhysicalFileProviderが存在しないルートディレクトリで構築された場合の問題を修正します。FileSystemWatcherが存在しないディレクトリを監視できないため、AddJsonFileで設定ファイルの親ディレクトリが起動時に未作成の場合にWatch()が失敗していました。

本修正では、PhysicalFilesWatcherがルートディレクトリの作成を遅延監視し、ルートが出現するまでFileSystemWatcherの有効化を延期します。PendingCreationWatcherが最も近い既存の親ディレクトリを非再帰的に監視し、中間ディレクトリレベルを通じてカスケード監視します。ルートディレクトリが存在するようになると、メインの再帰的FileSystemWatcherが有効になり、既に存在する監視対象エントリが報告されます。

変更内容

  • PhysicalFilesWatcher.cs: PendingCreationWatcher内部クラスを追加してルートディレクトリの作成を監視。TryEnableFileSystemWatcherがルート非存在時にEnsureRootCreationWatcherに遅延し、ルート出現時のコールバック機能を実装。ReportExistingWatchedEntriesがFSW有効化前に作成されたエントリのトークンを発火。コンストラクタが_rootの末尾区切り文字正規化と検証を実施。エラーハンドリングでワイルドカードトークン通知も実装。
  • PhysicalFileProvider.cs: 欠落ルートでDirectoryNotFoundExceptionをスローしなくなりました。Watchのドキュメントコメント更新。重複していた_pathSeparatorsフィールドを削除しPathUtils.PathSeparatorsを使用。
  • FileConfigurationSource.cs: ResolveFileProviderがファイルの直接親ディレクトリ(未作成の場合も含む)でPhysicalFileProviderを作成し、ウォッチャーに非存在ケース処理を委譲。
  • PollingFileChangeToken.cs: GetLastWriteTimeUtcFileInfo.Existsが偽の場合にDirectoryInfoチェックにフォールバック。DirectoryInfo遅延作成対応。
  • PathUtils.cs: PathSeparatorsinternalにして複数ファイル間での再利用を実現。
  • DirectoryInfoWrapper.cs: 存在チェック前にDirectoryInfoをリフレッシュして古い存在状態を回避。
  • テストファイル: 欠落ルート、ルート削除・再作成、サブディレクトリの作成/削除/再作成サイクル、ディレクトリ監視トークン、隠し属性ディレクトリ除外、FSWパス上下関係、兄弟ディレクトリプレフィックス隔離などに関する包括的なテストを追加。

パフォーマンスへの影響

非存在ルートの場合、以前の実装では最も近い既存ディレクトリを監視していたため、システム全体を監視する可能性がありました。本修正により、正確なルートディレクトリレベルの監視に制限され、不要な監視範囲拡大による大幅なパフォーマンス問題を解決します。

関連Issue

[#116713](https://github.com/dot


#126307 Close socket that leaks on connect failed

  • 作成者: @dovydenkovas
  • 作成日時: 2026年03月30日 11:32:27(UTC)
  • マージ日時: 2026年04月09日 08:19:08(UTC)
  • ラベル: area-VM-meta-mono community-contribution

概要

create_socket 関数がコネクション失敗時にソケットをクローズせずにリソースリークを起こしていた問題を修正しました。この関数は IdealGraphVisualizer グラフ生成時に使用され、デフォルトで 127.0.0.1:4445 に接続します。

変更内容

  • src/mono/mono/mini/cfgdump.c: コネクション失敗時のソケットクローズ処理を追加(+1/-0)

パフォーマンスへの影響

影響なし(リソースリーク修正のため、むしろリソース効率が向上)

関連Issue

#126307

その他

  • 影響範囲: Mono ランタイムの JIT コンパイラデバッグ機能(内部実装)
  • 公開APIへの影響なし
  • セキュリティ脆弱性ではなく、リソース管理の問題

#126065 Add Log10 to IBinaryInteger

  • 作成者: @ViveliDuCh
  • 作成日時: 2026年03月25日 00:47:08(UTC)
  • マージ日時: 2026年04月09日 19:19:09(UTC)
  • ラベル: area-System.Numerics

概要

IBinaryInteger<TSelf>インターフェースにLog10静的仮想メソッドを追加し、汎用数学API領域を拡張しています。すべてのプリミティブ整数型(bytesbyteshortushortintuintlongulongnintnuintcharInt128UInt128)とBigIntegerに最適化された実装を提供します。

変更内容

  • IBinaryInteger: Log10メソッドをstatic virtualとして追加し、デフォルト実装(DIM)として繰り返し10で除算するアルゴリズムを提供
  • プリミティブ型の実装: Log2ベースのアプローチとべき10検索テーブルを使用した最適化実装。符号付き型は負の入力をガード、符号なし型はゼロをvalue |= 1で処理
  • BigInteger: 明示的インターフェース実装で既存のpublic static double Log10(BigInteger)との競合を回避。Log2ベース推定とPow(10, approx)検証を使用
  • 参照アセンブリ: System.RuntimeSystem.Runtime.Numericsの参照アセンブリを更新
  • テスト: すべてのカバー型に対する包括的なテスト(べき10境界値検証含む)

パフォーマンスへの影響

影響なし。プリミティブ型の最適化実装により参照実装(DIM)と比較して高速ですが、具体的なベンチマーク数値は提供されていません。

関連Issue

#116043

その他

  • スコープ外: 以下は後続の作業で対応予定:CLongCULong、Vector APIs(Vector64<T>Vector512<T>)、Vector2Vector<T>TensorPrimitivesTensor<T>
  • 公開API変更: 新たにIBinaryInteger<TSelf>.Log10(TSelf value)がパブリックAPIとして追加される(破壊的変更ではなく、拡張)

#126045 Move shared Linux build pool defaults from Ubuntu 22.04 to Azure Linux 3

  • 作成者: @Copilot
  • 作成日時: 2026年03月24日 17:53:37(UTC)
  • マージ日時: 2026年04月09日 18:25:49(UTC)
  • ラベル: Servicing-approved area-Infrastructure

概要

dotnet/runtimeの共有Linux ビルドプール設定をUbuntu 22.04からAzure Linux 3に統一するパイプライン構成の更新。#125996で個別のパイプラインファイルがAzure Linux 3に移行済みだったため、共有デフォルトテンプレートeng/pipelines/common/xplat-setup.ymlも同様に更新し、リポジトリ全体で一貫性を取るもの。

変更内容

  • eng/pipelines/common/xplat-setup.yml:共有デフォルトプール設定を変更
    • 公開Linux池:Build.Ubuntu.2204.Amd64.Openbuild.azurelinux.3.amd64.open
    • 内部Linux池:1es-ubuntu-2204build.azurelinux.3.amd64
  • eng/pipelines/libraries/enterprise/linux.ymlhttp.ymlssl.yml:ストレステスト・エンタープライズパイプラインのプール設定をAzure Linux 3に統一

パフォーマンスへの影響

影響なし。パイプライン構成変更のみで、参照されるプールイメージはすでに検証済み。

関連Issue

#125996

その他

本変更はリグレッション修正ではなく前方互換の移行。Azure Linux 3プール名はすでに本リポジトリで評価パイプラインやライブラリパイプラインで使用されており、リスク評価は低い。パイプライン設定変更のみで、ランタイムやコンパイラの動作には影響しない。


#125539 Adding EnumMethodDefinitionByName, StartEnumMethodDefinitionsByName, and EndEnumMethodDefinitionsByName cDAC APIs

  • 作成者: @rcj1
  • 作成日時: 2026年03月13日 22:21:58(UTC)
  • マージ日時: 2026年04月09日 14:31:43(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

cDACレガシー層(IXCLRDataModule COM surface)に、メソッド定義を名前で列挙するための3つのAPI(StartEnumMethodDefinitionsByNameEnumMethodDefinitionByNameEndEnumMethodDefinitionsByName)を追加します。これにより、bpmdなどのデバッグツールがECMA-335メタデータを通じた名前ベースのメソッド検索が可能になります。

変更内容

  • IXCLRData.cs: CLRDataByNameFlag列挙型を導入(大文字小文字の区別を制御)
  • ClrDataModule.cs: メタデータリーダーを使用した方法定義の名前による列挙実装。StartEnumMethodDefinitionsByName/EnumMethodDefinitionByName/EndEnumMethodDefinitionsByNameを実装し、DEBUG時には従来のDACとの同期検証を行う(+244行)
  • ClrDataMethodDefinition.cs: IXCLRDataMethodDefinitionを実装するCOMクラスを新規追加(+127行)
  • IEnum.cs: エンumerator状態オブジェクト用の共通インターフェース追加(+17行)
  • SOSDacImpl.IXCLRDataProcess.cs: メソッドインスタンス列挙ヘルパーを新しいIEnum<T>パターンに合わせてリファクタリング
  • EnumMethodDefinitionsTests.cs: 名前解析とマッチング動作を検証する合成メタデータユニットテスト追加(+208行。名前空間の省略可、ネストされた型、ジェネリクス、コンストラクタ、大文字小文字の区別、オーバーロード数などをカバー)

パフォーマンスへの影響

影響なし

関連Issue

#125539

その他

  • 変更はcDACの内部実装層(Microsoft.Diagnostics.DataContractReader.Legacy)を対象としており、公開APIではありません
  • メソッド名の解析は、名前空間が省略可、ネストされた型に対して+/のセパレータ、ジェネリクス(バッククォート表記)、コンストラクタ名処理に対応しています
  • ローカルテストでは、様々なメソッド(コンストラクタ含む、名前空間の有無)に対してbpmdを使用して検証済み

#125283 TarReader: implement GNU sparse format 1.0 (PAX)

  • 作成者: @Copilot
  • 作成日時: 2026年03月06日 22:21:26(UTC)
  • マージ日時: 2026年04月09日 13:02:32(UTC)
  • ラベル: area-System.Formats.Tar

概要

TarReader が GNU sparse format 1.0(PAX)エントリに対応しました。これにより、bsdtar で作成されたアーカイブ(macOS/APFS の .NET SDK tarball など)から、内部プレースホルダーパス GNUSparseFile.0/real-file.dll の露出、不正なサイズ報告、破損したコンテンツ抽出が解決されます。PAX 拡張属性 GNU.sparse.major=1GNU.sparse.minor=0 が検出されると、実ファイル名を GNU.sparse.name から解決し、拡張サイズを GNU.sparse.realsize から取得し、生データストリームを GnuSparseStream でラップして仮想ファイルコンテンツ(ホールはゼロ、データは正しいオフセット)を提供します。

// Before: entry.Name == "GNUSparseFile.0/dotnet.dll", entry.Length == 512
// After:  entry.Name == "dotnet.dll", entry.Length == 1048576
using var reader = new TarReader(archiveStream);
TarEntry entry = reader.GetNextEntry();
entry.DataStream.ReadExactly(content); // correctly expanded virtual file

変更内容

  • TarHeader.cs: GNU sparse 1.0 エントリの認識・表現に必要な内部状態を追加
  • TarHeader.Read.cs: GNU sparse PAX 属性を処理し、sparse 拡張ストリームラッパーを生成
  • TarEntry.cs: 拡張エントリに対して Length/DataStream が拡張サイズ/コンテンツを公開するよう更新
  • GnuSparseStream.cs (新規): sparse map の遅延パース + 仮想ファイルストリーム動作を実装(542 行)
  • TarReader.SparseFile.Tests.cs (新規): sparse レイアウト、不正なマップ、ラウンドトリップ、実コーパスファイルなど包括的なテストを追加(576 行)
  • プロジェクトファイル更新: 新規ファイルをビルドに含める

パフォーマンスへの影響

  • Sparse map の解析は遅延評価(初回 Read 時)に実装されており、エントリ構築時に _dataStream が消費されません。これにより TarWriter.WriteEntry は圧縮済み sparse データを正しくラウンドトリップ可能
  • FindSegmentFromCurrent は後方シークで二分探索(O(log n))を使用し、一般的な順序読みの O(1) 償却性能を保持
  • オフセット検証はオーバーフロー安全な算術式を使用(offset > _realSize || length > _realSize - offset

関連Issue

#125283

その他

  • 読み取り専用サポート。GNU sparse format 0.0、0.1 および書き込みサポートは未対応
  • GnuSparseStreamDisposeAsync をオーバーライドして基盤ストリームの非同期破棄を正しく待機
  • TarHeader.Read は負の GNU.sparse.realsizeInvalidDataException をスロー(通常の _size フィールド検証と一貫性)
  • 既存テスト全てがパス。新規テストは実 golang_tar テストデータファイル(`System

#125174 JIT: Share suspension epilogs in async transformation

  • 作成者: @jakobbotsch
  • 作成日時: 2026年03月04日 13:12:35(UTC)
  • マージ日時: 2026年04月09日 12:36:56(UTC)
  • ラベル: area-CodeGen-coreclr

概要

CoreCLR JITの非同期変換において、複数のawaitが存在する場合に共有のGT_RETURN_SUSPENDブロックを生成し、複数のサスペンション地点が単一のエピログにブランチするよう最適化します。これによりR2R(Ready-to-Run)バイナリサイズが削減されます。

変更内容

  • src/coreclr/jit/async.h: await検出、tail-await一括変換、共有リターンブロック生成の宣言を追加
  • src/coreclr/jit/async.cpp:
    • FindAwaits(...)関数を追加して通常のawaitとtail-awaitを区別してカウント
    • TransformTailAwaits(...)でtail-awaitを優先処理し、必要に応じて再スキャン
    • CreateSharedReturnBB()#awaits > 1の場合に共有GT_RETURN_SUSPENDブロックを生成
    • tail-awaitサスペンションを共有リターンブロック使用に更新

パフォーマンスへの影響

バイナリサイズ削減(R2R x64):

  • System.IO.Compression.dll: -4.0 KB (-0.89%)
  • System.Linq.AsyncEnumerable.dll: -4.0 KB (-0.34%)
  • System.Net.Http.dll: -4.0 KB (-0.25%)
  • System.Private.Xml.dll: -4.0 KB (-0.05%)

コード生成の効率化により、複数awaitを含むメソッドのバイナリサイズが削減されます。実行時パフォーマンスへの直接的な影響は明記されていません。

関連Issue

なし

その他

作成者のgistで詳細なASP.NET+Runtime非同期クロスジェン2差分が提供されています。これは内部実装(JIT変換パイプライン)の改善であり、公開APIには影響しません。


#124405 Backport XML docs for System.Diagnostics.FileVersionInfo from dotnet-api-docs

  • 作成者: @Copilot
  • 作成日時: 2026年02月13日 22:58:08(UTC)
  • マージ日時: 2026年04月09日 00:01:28(UTC)
  • ラベル: area-System.Diagnostics

概要

System.Diagnostics.FileVersionInfoの公開APIに対するXML ドキュメンテーションをdotnet-api-docsからソース実装にバックポートするコミットです。すべての公開メンバーに<summary><value><param><returns>タグを追加し、int型プロパティがバージョン情報欠落時にnullではなく0を返すことを正しく記載しています。

サンプル:

/// <summary>
/// Gets the build number of the file.
/// </summary>
/// <value>A value representing the build number of the file or 0 (zero) if the file did not contain version information.</value>
public int FileBuildPart { get; }

変更内容

  • FileVersionInfo.cs (+35/-8): すべての公開メンバーにXMLドキュメンテーションコメントを追加。FileBuildPartFilePrivatePartProduct*Partなどのint型プロパティについて、バージョン情報欠落時の戻り値を0と正確に記載
  • System.Diagnostics.FileVersionInfo.csproj (+0/-1): コンパイラ生成ドキュメントの除外設定を削除し、インライン XMLドキュメントの使用を有効化

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

本変更はdotnet/runtime#124227のパターンに従っています。ドキュメンテーションの正確性が向上し、IntelliSenseやドキュメント生成時に正しい情報が提示されるようになります。


#117473 Box value types implementing IXmlSerializable in XmlSerializer generated IL

  • 作成者: @daeghanelkin
  • 作成日時: 2025年07月09日 19:15:26(UTC)
  • マージ日時: 2026年04月09日 18:11:10(UTC)
  • ラベル: area-Serialization community-contribution

概要

IXmlSerializableインターフェースを実装するパラメータなしコンストラクタを持つ値型が、XmlSerializerの生成IL内で適切にボックス化されていなかった問題を修正します。この問題により、XmlSerializationReader.ReadSerializableメソッド呼び出し時にInvalidProgramException例外が発生していました。

修正内容:パラメータなしコンストラクタを持つ値型をインターフェース型として引き渡す際に、box命令をIL生成時に明示的に追加することで、値型の適切なボックス化を保証します。

変更内容

  • src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

    • IL生成ロジックにbox命令を追加(2行追加)。パラメータなしコンストラクタを持つ値型に対するnewobj命令後にボックス化処理を挿入
  • src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.cs

    • パラメータなしコンストラクタを持つ値型の逆シリアル化テストケース追加(38行追加)
  • src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.cs

    • IXmlSerializable実装の値型テストケース追加(55行追加)
  • src/libraries/Microsoft.XmlSerializer.Generator/tests/Expected.SerializableAssembly.XmlSerializers.cs

    • 期待値テストファイルの更新(1234→1332行)

パフォーマンスへの影響

影響なし。この修正は正確性を目的とし、ボックス化は既にコンパイラが他の同等ケースで生成していたため、追加のパフォーマンスオーバーヘッドはありません。

関連Issue

#99613

その他

修正者は「IL生成に関して完全な専門知識を持たない」と記述しており、変更内容はMicrosoft.XmlSerializer.Generatorツールが生成するC#出力の比較分析に基づいています。パラメータなしコンストラクタを持たない値型はsm.TypeDesc.CannotNew条件により既に正しくボックス化されているため、この修正の影響範囲は限定的です。


目次