Pull Request on 2026年03月06日

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

注意点

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



#125258 Remove some unnecessary EventSource suppressions

  • 作成者: @agocke
  • 作成日時: 2026年03月06日 07:29:56(UTC)
  • マージ日時: 2026年03月06日 18:48:31(UTC)
  • ラベル: area-System.Diagnostics.Tracing

概要

EventSource型に付与されたDynamicallyAccessedMembersAttributeによる不要なトリム解析抑制を削除するため、マニフェスト生成や属性リフレクションのヘルパーメソッドをネストされたプライベート型EventSourceHelpersに移動しました。これにより、NativeAOTでの保持されるメタデータ量を削減し、抑制アノテーションの必要性を排除します。

// 変更前: EventSourceに直接メソッドがあり、DAM属性により抑制が必要
// 変更後: ネストされた型に移動して反射可視性から除外
private static class EventSourceHelpers
{
    public static Guid GetGuid(Type eventSourceType) { ... }
    public static string GetName(Type eventSourceType) { ... }
    // CreateManifestAndDescriptors, GetCustomAttributeHelperもここに移動
}

変更内容

  • EventSource.cs: マニフェスト生成、属性初期化、Guid/Name取得などのヘルパーメソッドを新たに作成されたEventSourceHelpersネストされた型に移動
  • GetGuidGetNameCreateManifestAndDescriptorsGetCustomAttributeHelperをプライベート型内に再配置
  • 複数の#pragma warning suppressディレクティブを削除可能に

パフォーマンスへの影響

改善: NativeAOT環境でメタデータ保持量が削減されます。EventSourceHelpersをネストされた型にすることで、トリマーが反射スコープから除外でき、不要なメタデータ保存を回避します。一般的なランタイム実行性能への直接的な影響はありませんが、AOTコンパイル後のバイナリサイズ削減が期待できます。

関連Issue

なし

その他

  • 互換性: EventSourceHelpersはプライベート型で内部実装のため、パブリックAPIの変更なし
  • 保守性: トリム解析抑制の削除により、コード可読性が向上し、将来のメンテナンスが容易化

#125242 Remove obsolete ILLink dependency analyzer project and references

  • 作成者: @Copilot
  • 作成日時: 2026年03月05日 22:02:52(UTC)
  • マージ日時: 2026年03月06日 17:17:26(UTC)
  • ラベル: linkable-framework area-Tools-ILLink

概要

このPRは、dotnet/runtimeリポジトリから未使用のILLink dependency analyzerプロジェクトを削除し、それに関連するすべてのビルド設定、ソリューション定義、ドキュメント参照をクリーンアップします。ILLinkツールセットを実装メンテナンス対象コンポーネントのみに整理するための整理PRです。

変更内容

  • ビルドグラフ: eng/Subsets.propsからsrc/tools/illink/src/analyzer/analyzer.csprojを削除(tools.illinkサブセット)
  • ソリューション定義: src/tools/illink/illink.slnxtrimming.slnxからアナライザープロジェクト参照を削除
  • ソースコード削除: src/tools/illink/src/analyzer/ディレクトリ全体を削除(プロジェクトファイル、実装、ドキュメント)
  • ドキュメント更新: src/tools/illink/README.mdの"Dependencies Analyzer"セクションを削除

パフォーマンスへの影響

影響なし。削除のみであるため、パフォーマンスへの直接的な影響はありません。ビルド時間が若干短縮される可能性があります(~1000行のソースコード削除)。

関連Issue

なし

その他

  • 削除対象:約1,000行のソースコード(analyzer実装、プロジェクト設定、ドキュメント)
  • 破壊的変更なし:削除されるのは未使用のツールのみ
  • Copilotによる自動レビュー完了:10ファイル中10ファイルで問題なし

#125239 [RyuJit] Remove dead code from genCallInstruction

  • 作成者: @SingleAccretion
  • 作成日時: 2026年03月05日 21:40:30(UTC)
  • マージ日時: 2026年03月06日 16:18:53(UTC)
  • ラベル: area-CodeGen-coreclr community-contribution

概要

RyuJit コードジェネレータの genCallInstruction メソッドから不要なデッドコードを削除するリファクタリング。gtDirectCallAddress は lowering フェーズで既にすべての呼び出し種別に対して設定されているため、code generation フェーズで冗長なチェックと初期化コードが削除された。

変更内容

  • src/coreclr/jit/codegenarmarch.cpp: 25行削除(デッドコード除去)
  • src/coreclr/jit/codegenloongarch64.cpp: 25行削除(デッドコード除去)
  • src/coreclr/jit/codegenriscv64.cpp: 26行削除(デッドコード除去)
  • src/coreclr/jit/codegenxarch.cpp: 31行削除(デッドコード除去)
  • src/coreclr/jit/lower.cpp: lowering フェーズでの処理確認(コメント追加等)

複数のアーキテクチャ実装(ARM、LoongArch64、RISC-V、x86/x64)で同様のデッドコード削除が行われており、一貫性のあるリファクタリング。

パフォーマンスへの影響

影響なし。このPRはコード生成ロジックの削除ではなく、既に実行されていないデッドコードの除去であるため、ランタイムパフォーマンスへの影響はない。JIT コンパイル時間は若干短縮される可能性がある(冗長なチェック処理の削除により)。

関連Issue

なし

その他

  • 複数のアーキテクチャにまたがる一貫したリファクタリングであり、コード保守性の向上を目的とした変更
  • lowering フェーズとcode generation フェーズの責任分離が改善され、デッドコードの排除によりコード行数が約110行削減される
  • 破壊的変更ではなく、純粋なコード品質向上の変更

#125236 [cDAC] Relax HRESULT validation to allow divergent failure codes

  • 作成者: @max-charlamb
  • 作成日時: 2026年03月05日 20:53:22(UTC)
  • マージ日時: 2026年03月06日 14:17:05(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

cDAC(Compact Data Access Component)のDEBUGバリデーションにおいて、cDACとレガシーDAC間のHRESULT比較を緩和します。従来は完全一致を要求していましたが、今後は両者が異なるエラーコード(負の値)を返す場合でも許容し、デバッガプロセスのクラッシュを回避します。成功コード(S_OKS_FALSE)は引き続き完全一致を要求します。

// 変更前
Debug.Assert(hrLocal == hr, $"cDAC: {hr:x}, DAC: {hrLocal:x}");

// 変更後
Debug.ValidateHResult(hr, hrLocal);

変更内容

  • DebugExtensions.cs(新規)Debug.ValidateHResult()メソッドとそれを制御するHResultValidationMode列挙型を追加
    • Exactモード:HRESULT完全一致が必須
    • AllowDivergentFailuresモード(デフォルト):成功コードは一致必須、エラーコード(負値)は任意の失敗を許容
  • SOSDacImpl.cs他4ファイル — 113箇所のアサーション(HRESULT完全一致チェック)を新しいDebug.ValidateHResult()に統一

パフォーマンスへの影響

影響なし。検証ロジックが集約されるだけで、実行時性能の変化はありません。ただしDEBUGビルドにおいて不要なアサーション失敗による予期しないデバッガ終了(テストの不安定性)が解消されます。

関連Issue

提起されたテスト不安定性:cDAC_windows_x64_releaseジョブのSOS.VarargPInvokeInteropMDテストで、cDACと内部DACが異なるエラーコード(0x80131C49 vs 0x80070057)を返すために致命的アサーション失敗が発生していた問題を解決します。

その他

  • 公開APIに対する破壊的変更はなく、内部バリデーション層のみの改善です
  • ClrMD、SOS、マネージドデバッガなどの消費者は呼び出し元で成功/失敗判定のみ行い、特定エラーコードで分岐していないため、このAPIの動作変更に対応する必要はありません

#125235 Fix bounds checks in #123085 repro

  • 作成者: @EgorBo
  • 作成日時: 2026年03月05日 19:50:06(UTC)
  • マージ日時: 2026年03月06日 13:06:05(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラの範囲チェック最適化における境界チェックのバグを修正しました。(X + negativeConst) u< Y形式の符号なし比較式で、負の定数を含む場合の推論ロジックを改善し、X >= -negativeConstという制約を正しく推導できるようになりました。

変更内容

  • src/coreclr/jit/rangecheck.cpp: 境界チェック推論ロジックの修正(+32行/-9行)
    • 符号なし比較(unsigned less than)での負の定数ハンドリングを改善
    • Yが非負であることが証明されている場合の制約推導を修正

パフォーマンスへの影響

影響なし(バグ修正による正確な最適化のため、パフォーマンス劣化の可能性は低い)

関連Issue

  • #123085(本修正の対象Issue)
  • #125235(修正の再現テストケース)

その他

本修正はJITの範囲チェック最適化の正確性に関するバグ修正です。符号なし比較における負の定数の取り扱いが不正確だったため、配列アクセスなどの境界チェック削除時に不適切な最適化が行われていた可能性があります。修正により、より安全で正確な最適化が実施されるようになります。


#125232 [Tests][UserEvents] Bump tracee timeout and add logs

  • 作成者: @mdh1418
  • 作成日時: 2026年03月05日 18:35:56(UTC)
  • マージ日時: 2026年03月06日 16:05:29(UTC)
  • ラベル: area-Tracing-coreclr

概要

ユーザーイベントトレーシングテストのタイムアウト値を5秒から10秒に延長し、デバッグログを追加するテスト修正です。JITストレステストレーンで実行中にタイムアウトが発生していた問題に対応しています。record-traceがどのプロセスの.NETイベントを有効化したか、またTraceeプロセスがEventSourceで待機・受信したかをログに記録することで、テスト失敗時のデバッグを改善しています。

変更内容

  • src/tests/tracing/userevents/common/UserEventsTestRunner.cs
    • Traceeプロセスのタイムアウト値を5秒から10秒に延長
    • Tracee待機時のログ出力を追加(EventSource有効化確認)
    • record-traceプロセスがイベント有効化したプロセスPIDをログに記録する処理を追加

パフォーマンスへの影響

テスト実行時間の増加:タイムアウトの延長により、最大5秒の追加待機が発生する可能性があります。ただし、通常の環境では既存完了時間内に終了するため、実際の影響は軽微です(jitstressレーン以外での性能低下なし)。

関連Issue

#123442

その他

  • JITストレステストレーン(既知の遅い実行環境)での信頼性向上が主な目的
  • ログ出力により、トレースイベントの有効化タイミングとプロセス間通信(IPC)の状態が可視化され、テスト失敗時の原因特定が容易になります
  • テストランナーの互換性に影響はなし

#125225 Fix getAsyncOtherVariant JIT-EE implementation in VM

  • 作成者: @jakobbotsch
  • 作成日時: 2026年03月05日 15:41:16(UTC)
  • マージ日時: 2026年03月06日 00:13:11(UTC)
  • ラベル: area-CodeGen-coreclr runtime-async

概要

このPRは、getAsyncOtherVariant JIT-EE実装において、ペアになった非同期バリアントが存在しないメソッド(AsyncHelpers.Awaitなど)に対して無効な呼び出しが発生する問題を修正します。EnableExtraSuperPmiQueriesモードで両方のバリアントをプロアクティブにクエリする際に問題が発生していました。また、SuperPMI実装の記録処理も簡素化されています。

// HasAsyncOtherVariant() で保護
if (pMethodDesc->HasAsyncOtherVariant())
{
    CORINFO_METHOD_HANDLE otherVariant = pMethodDesc->GetAsyncOtherVariant();
    // 処理
}

変更内容

  • method.hpp: HasAsyncOtherVariant() メソッド追加と GetAsyncOtherVariant() の事前条件をアサート
  • methodtablebuilder.cpp: メソッドテーブルビルダーで非存在の非同期バリアント要求をガード
  • jitinterface.cpp: JIT-EEが明示的に非同期メソッド(ペアなし)に対して GetAsyncOtherVariant() を呼び出さないように修正
  • superpmi関連ファイル: SPMI shim collector の記録APIを簡素化(ポインタから値渡しへ変更)
  • corinfo.h: APIコメントで variantIsThunk の意味を明確化

パフォーマンスへの影響

影響なし。本修正は不正な呼び出しを防ぐための制御フロー改善であり、パフォーマンスへの直接的な影響はありません。むしろ不正な呼び出しオーバーヘッド削減による軽微な改善が期待できます。

関連Issue

なし

その他

  • 破壊的変更: なし(内部実装の修正)
  • 互換性: 公開API変更なし
  • テスト対象: EnableExtraSuperPmiQueries モードを含むJIT-EE動作検証が必要

#125222 Change bbAssertionOut if BBJ_COND was folded in morph

  • 作成者: @EgorBo
  • 作成日時: 2026年03月05日 14:00:21(UTC)
  • マージ日時: 2026年03月06日 11:34:54(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラの条件分岐フォールディング処理において、BBJ_CONDがフォールドされた場合のbbAssertionOutの更新ロジックを改善しました。アサーション伝播の正確性を向上させる修正です。

変更内容

  • src/coreclr/jit/assertionprop.cpp: 条件分岐がフォールドされた際のbbAssertionOut更新ロジックを追加(+48行)
    • BBJ_CONDフォールディング後のアサーション集合の管理を改善
    • 以前のIssue #125093で指摘されたアサーション集合の整合性問題に対応

パフォーマンスへの影響

影響なし。本変更はアサーション追跡ロジックの正確性向上であり、実行時パフォーマンスに直接的な影響はありません。

関連Issue

#125093(アサーション集合に関する懸念事項)

その他

本PRはコードレビュー段階で、AndyAyersMS氏からの指摘に対応する修正です。JIT最適化の信頼性向上に寄与する変更であり、コンパイラの正確な最適化判断を支援します。


#125216 [wasm][coreclr] Re-enable few runtime tests

  • 作成者: @radekdoulik
  • 作成日時: 2026年03月05日 11:47:52(UTC)
  • マージ日時: 2026年03月06日 12:48:11(UTC)
  • ラベル: arch-wasm area-Infrastructure-coreclr

概要

WASM環境でSystem.BadImageFormatExceptionにより скipped されていた静的仮想メソッド(Static Virtual Methods)の3つのランタイムテストを再度有効化します。基盤となる問題(issue #124259、#124260)が修正されたため、テストが正常に動作するようになったことに伴う変更です。

変更内容

  • svm_diamondshape.il: ActiveIssueAttribute(#124259)を削除し、WASMプラットフォームでのテストスキップを解除
  • AmbiguousImplementationException.il: ActiveIssueAttribute(#124259)を削除し、WASMプラットフォームでのテストスキップを解除
  • Reabstraction.il: ActiveIssueAttribute(#124259)を削除し、WASMプラットフォームでのテストスキップを解除

すべてsrc/tests/Loader/classloader/StaticVirtualMethods/配下のテストファイルで、各ファイルから5行の属性情報が削除されています。

パフォーマンスへの影響

影響なし。本変更はテストカバレッジの追加に関連するものであり、ランタイムのパフォーマンスへの直接的な影響はありません。

関連Issue

その他

本変更はWASM(WebAssembly)プラットフォーム対応の改善に関連しています。静的仮想メソッドはC# 11以降の機能であり、インターフェースのジェネリック実装に関連する複雑なテストケースのカバレッジが復活したことを意味します。


#125214 JIT: Handle some def/use conflicts less conservatively in LSRA

  • 作成者: @jakobbotsch
  • 作成日時: 2026年03月05日 11:24:22(UTC)
  • マージ日時: 2026年03月06日 20:19:50(UTC)
  • ラベル: area-CodeGen-coreclr

概要

LSRA (Linear Scan Register Allocator) における def-use conflict の解決ロジックを改善しました。特に case 1 と case 2 の条件判定が過度に保守的だったため、defRegConflictuseRegConflict 変数の意味を正確に復元し、より効率的なレジスタ割り当てが可能になります。これにより、不要なスピリングやコピーが減少し、生成されるコードの品質が向上します。

変更内容

  • src/coreclr/jit/lsrabuild.cpp: def-use conflict 解決時の条件判定ロジックを修正(+15/-4)
    • defRegConflictuseRegConflict 変数の定義を、単なる「レジスタ制約の競合」から「解決に使用できる異なるレジスタの競合」に変更
    • これまで到達不可能だった case 1, case 2 の判定条件を正確化

パフォーマンスへの影響

改善あり。より多くの def-use conflict ケースで効率的な解決方法が適用可能になり、以下の点で改善が期待されます:

  • 不要なレジスタ spilling の削減
  • 不要なコピー命令の削減
  • 生成されるマシンコードの効率化

ただし、具体的なベンチマーク数値は本 PR の情報には含まれていません。

関連Issue

なし

その他

この変更は LSRA の内部ロジック(JIT コンパイラのレジスタ割り当てアルゴリズム)の改善であり、API 互換性への影響はありません。런타임 性能向上の最適化です。


#125201 Fix NTLM ProcessTargetInfo returning wrong buffer slice when skipping entries

  • 作成者: @Copilot
  • 作成日時: 2026年03月05日 02:50:18(UTC)
  • マージ日時: 2026年03月06日 11:11:29(UTC)
  • ラベル: area-System.Net.Security

概要

管理型NTLM認証のProcessTargetInfoメソッドにおいて、サーバーチャレンジにTargetNameまたはChannelBindings AV pairが含まれる場合、バッファスライスのオフセット指定が誤りで未使用部分(ゼロ詰め)を返していた。単一文字の修正で、正しい書き込み済み部分を返すよう改正。

// Before
return targetInfoBuffer.AsSpan(targetInfoOffset).ToArray();

// After
return targetInfoBuffer.AsSpan(0, targetInfoOffset).ToArray();

変更内容

  • NegotiateAuthenticationPal.ManagedNtlm.cs: ProcessTargetInfoの戻り値を修正。バッファの書き込み済み領域(0からtargetInfoOffsetまで)を返すように変更。
  • FakeNtlmServer.cs: テストインフラにSendPreExistingTargetNameSendPreExistingChannelBindingsプロパティを追加し、チャレンジに既存のAV pairを含めることで、スキップ処理をトリガーできるように拡張。
  • NegotiateAuthenticationTests.cs: NtlmWithPreExistingTargetInfoEntriesTestを追加。管理型NTLMが有効なプラットフォーム(Ubuntu 24/26、OpenSUSE 16)でのみ実行される条件付きテストで、TargetName/ChannelBindingsの各組み合わせ(true,false)、(false,true)、(true,true)でNTLM認証フロー全体が成功することを検証。

パフォーマンスへの影響

影響なし。バッファスライス引数の1文字修正であり、プロトコルロジックは変更されていない。

関連Issue

#125201

その他

顧客への影響: サーバーがチャレンジのtarget infoにTargetNameまたはChannelBindingsエントリを含める場合、破損したtarget infoによってHMAC検証がサーバー側で失敗し、認証が完全に失敗していた。これは事前存在するバグで、テストサーバー(FakeNtlmServer)がこれらのAV pairを生成していなかったため発見されていなかった。

リスク評価: 低。修正は単一文字変更で、影響を受けるコードパスはテストでは到達不可能だった。新規テストにより正確性を検証済み。既存122個のユニットテストはすべてパス。


#125132 [cDAC] Add custom marshallers for COM interface parameters

  • 作成者: @max-charlamb
  • 作成日時: 2026年03月03日 17:21:43(UTC)
  • マージ日時: 2026年03月06日 17:52:46(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

COM相互運用性のためのカスタムマーシャラーをcDAC(Common Data Access Component)に追加しています。特にDacComNullableByRefという新しいマーシャラーを実装し、COM インターフェース パラメータの正確なマーシャリングを改善しました。複数のISOSDacInterfaceおよびIXCLRDataインターフェース実装において、パラメータ方向と型情報の定義を更新しています。

変更内容

  • 新規ファイル: DacComNullableByRef.cs (+136行) - COM相互運用用のカスタムマーシャラー実装
  • ISOSDacInterface.cs: インターフェース定義を拡張 (+70/-9行)
  • IXCLRData.cs: パラメータ定義を更新 (+121/-121行) - 方向属性やマーシャリング情報の追加
  • SOSDacImpl関連ファイル: 複数の実装クラスでパラメータ処理を調整
    • ClrDataMethodInstance.cs (-15行削減)
    • ClrDataModule.cs (+15行)
    • その他ClrData*.csで軽微な変更
  • テスト: ClrDataTaskTests.cs (+4/-3行)

パフォーマンスへの影響

影響なし。本変更はマーシャリングの正確性向上に焦点を当てており、パフォーマンス最適化ではありません。

関連Issue

なし

その他

  • cDACはランタイム診断メタデータアクセスのための重要なコンポーネント
  • COM インターフェース相互運用性の堅牢化により、マネージド/ネイティブ境界でのデータ転送の信頼性が向上
  • DacComNullableByRefマーシャラーはnullable参照型のCOM相互運用対応と推定

#125102 [Wasm RyuJit] More crossgen assert fixes

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年03月03日 04:40:05(UTC)
  • マージ日時: 2026年03月06日 15:34:03(UTC)
  • ラベル: arch-wasm area-CodeGen-coreclr

概要

WebAssembly RyuJit JITコンパイラでのアサーション失敗を修正するPRです。オーバーフロー検査、nullチェック、putargスタック処理に関する複数の問題を対処し、コンパイラの安定性向上を目指しています。

変更内容

  • codegenwasm.cpp: gtOverflow → gtOverflowEx への変更、nullチェック処理の改善(+29/-5)
  • lower.cpp: putargスタック関連のロジック修正(+21/-4)
  • lowerwasm.cpp: addローイング時のオーバーフロー検査バイパスの修正(+7/-1)
  • regallocwasm.cpp/h: レジスタ割り当ての補助ロジック追加(+17/-0, +1/-0)
  • stacklevelsetter.cpp: スタックレベル設定時のnullチェック許容化(+9/-1)

パフォーマンスへの影響

影響なし。本修正はアサーション失敗時のコンパイル信頼性向上を主目的としており、生成コードのパフォーマンスには直接的な影響はありません。

関連Issue

#125102(親Issue)、#125203(nullチェック許容化に関連)

その他

  • Wasm固有の複数のJIT・コードジェン処理を対象とした包括的な修正
  • オーバーフロー例外処理、メモリアクセス検証などランタイム保証に関わる重要な修正
  • 内部実装変更のため、ユーザーコードへの直接的な影響はなし

#125092 Remove resolved ActiveIssue(#14378) skip attributes from IO.FileSystem tests

  • 作成者: @Copilot
  • 作成日時: 2026年03月03日 01:31:58(UTC)
  • マージ日時: 2026年03月06日 17:50:45(UTC)
  • ラベル: area-System.IO

概要

Issue #14378が解決されたにもかかわらず、System.IO.FileSystemテストで6つのテストメソッドが[ActiveIssue]属性で永遠にスキップされていました。このPRでは、これらのスキップ属性を削除し、テストを再度有効化します。マウントボリュームテストはNTFSドライブでのみ実行され、not-readyドライブテストはプラットフォーム固有の条件付きスキップに変更されています。

変更内容

  • Delete_MountVolume.csRunTestメソッドの[ActiveIssue]を削除、[ConditionalFact(nameof(IsNtfs))]で保護(NTFSドライブのみで実行)
  • ReparsePoints_MountVolume.csrunTestメソッドの[ActiveIssue]を削除、同じく[ConditionalFact(nameof(IsNtfs))]で保護
  • Exists.cs — 2つのnot-readyドライブテストの[ActiveIssue]を削除、[ConditionalFact]に変更し、テスト本体でthrow new SkipTestException(...)を実装
  • CreateDirectory.cs — 2つのnot-readyドライブテストの[ActiveIssue]を削除、同様に[ConditionalFact]に変更しSkipTestExceptionを実装

パフォーマンスへの影響

影響なし。本変更はテストの実行可能性に関するもので、ランタイムパフォーマンスへの直接的な影響はありません。

関連Issue

Issue #14378(解決済み)

その他

  • すべてのテストは[PlatformSpecific(TestPlatforms.Windows)]を保持しており、非Windowsプラットフォームではスキップされます
  • not-readyドライブテストは、従来の「Console.WriteLine + return」パターン(テストが0個のアサーションで黙って通過)をSkipTestExceptionに置き換えることで、テストが適切に「スキップ」として報告されるようになります
  • マウントボリュームテストはSetVolumeMountPoint Win32 API(NTFSドライブが必須)の要件に基づいています

#125091 Allocate all long-lived contents of interpreter memory via the jit interface allocation apis

  • 作成者: @davidwrighton
  • 作成日時: 2026年03月03日 01:08:30(UTC)
  • マージ日時: 2026年03月06日 03:17:01(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

インタプリタの長期保持メモリをJIT インターフェース allocation API経由で一括割り当てするように変更。collectible assemblyからのメモリリーク問題の解決を目的としています。

変更内容

  • compiler.cpp/h: メモリ割り当てロジックを拡張し、JIT allocation APIを使用した一括割り当て機構を実装
  • interpmethoddata.cpp/h: インタプリタメソッドデータ用の新規割り当てヘルパー実装(計250行追加)
  • interpalloc.h/interpmemkind.h: 割り当て関連の新規ヘッダーとメモリ種別定義を追加
  • eeinterp.cpp: 既存の割り当てロジックをリファクタリング
  • CMakeLists.txt: ビルド構成を更新

パフォーマンスへの影響

影響なし(メモリ管理の改善であり、実行時パフォーマンスへの直接的な影響は記載されていません)

関連Issue

なし

その他

  • 複数のCopilotレビュアーボットがレビューを実施
  • ビルドシステム変更を含む包括的なメモリ割り当て統一化
  • collectible assemblyのメモリリーク修正により、動的アセンブリ生成シナリオでの安定性向上が期待できます

#125089 Skip cross process mutex on OpenBSD

  • 作成者: @sethjackson
  • 作成日時: 2026年03月03日 00:14:28(UTC)
  • マージ日時: 2026年03月06日 12:03:47(UTC)
  • ラベル: area-System.Threading community-contribution os-openbsd

概要

OpenBSDではクロスプロセスミューテックスに必要なPOSIX関数(pthread_mutexattr_setrobustpthread_mutexattr_setpsharedpthread_mutex_consistent)がサポートされていないため、OpenBSD環境ではクロスプロセスミューテックス機能をスキップする対応を実施しました。これにより、OpenBsdでのPlatformNotSupportedExceptionを適切に処理するようにしています。

変更内容

  • System/OperatingSystem.cs: OpenBSD判定用のプロパティまたはメソッドを追加(+13行)
  • System/Threading/NamedMutex.Unix.cs: OpenBSD環境でのクロスプロセスミューテックス機能をスキップするロジックを追加(+2/-1行)
  • src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems: プロジェクト設定の更新(+1行)
  • CMakeLists.txt: ネイティブライブラリのビルド設定を調整(+1/-1行)

パフォーマンスへの影響

影響なし。本変更はOpenBSD上でのプラットフォーム機能の可用性判定に関するもので、実行時パフォーマンスへの影響はありません。

関連Issue

#124911

その他

OpenBSDではクロスプロセスミューテックス機能が利用できないため、該当機能を使用しようとした場合はPlatformNotSupportedExceptionが発生します。これはプラットフォームの制限事項に対する適切な対応です。


#125063 Fix zstd install rules breaking clr.runtime clean build

  • 作成者: @rzikm
  • 作成日時: 2026年03月02日 17:50:18(UTC)
  • マージ日時: 2026年03月06日 07:46:10(UTC)
  • ラベル: area-Infrastructure-coreclr

概要

クリーンビルドでclr.runtimeをビルド時にCMakeインストール失敗する問題を修正しました。FetchContentEXCLUDE_FROM_ALL付きのadd_subdirectory()に置き換え、zstdのインストールルールがコンポーネントインストールに含まれるのを防ぎます。

変更内容

  • src/native/external/zstd.cmake: FetchContent_MakeAvailable(zstd)からadd_subdirectory(${zstd_SOURCE_DIR} ${zstd_BINARY_DIR} EXCLUDE_FROM_ALL)に変更(8行追加、9行削除)

パフォーマンスへの影響

影響なし

関連Issue

#124234

その他

  • CMake 3.14以降でEXCLUDE_FROM_ALLはインストールルール抑制が確実に動作
  • プロジェクト最小CMakeバージョンが3.26のため互換性に問題なし
  • System.IO.Compression.Native/CMakeLists.txtの明示的なinstall()呼び出しは従前通り動作(libzstd_staticターゲットを直接指定しているため)

#124918 [cDAC] Add continuation support to RuntimeTypeSystem

  • 作成者: @max-charlamb
  • 作成日時: 2026年02月26日 18:45:57(UTC)
  • マージ日時: 2026年03月06日 18:13:40(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

このPRはcDAC (Common Data Access Component) の RuntimeTypeSystem コントラクトに continuation サポートを追加します。非同期 continuation 機能で動的に作成される MethodTable を識別・検証できるようになります。continuation は配列やジェネリック型と同様に特殊な MethodTable であり、基本 Continuation クラスを親として持つため、既存の MT→EEClass→MT 検証ラウンドトリップでは拒否されていました。

// IsContinuation を使用して continuation MethodTable を識別
if (runtimeTypeSystem.IsContinuation(typeHandle))
{
    // continuation MethodTable の特殊な処理
}

変更内容

  • datadescriptor.incg_pContinuationClassIfSubTypeCreatedContinuationMethodTable グローバルポインタとして公開
  • IRuntimeTypeSystem.csIsContinuation(TypeHandle) メソッドをコントラクトインターフェースに追加
  • RuntimeTypeSystem_1.csParentMethodTable == continuationMethodTablePointer の比較で実装
  • RuntimeTypeSystemFactory.cs — continuation MT グローバルを読み込み(欠落時は TryReadGlobalPointer で安全に処理)
  • TypeValidation.cs — MT→EEClass→MT 検証を修正して continuation を許可(配列・ジェネリック型と同様に扱う)
  • Constants.csContinuationMethodTable 定数名を追加
  • テスト追加 — 4つのテストメソッド(8ケース): 真陽性、真陰性、null グローバル、CanonMT 検証

パフォーマンスへの影響

影響なし。本変更はメタデータ検証ロジックの追加であり、runtime パフォーマンスには影響しません。

関連Issue

https://github.com/dotnet/runtime/pull/124780#discussion_r2860213806

その他

  • continuation は配列やジェネリック型と同様に特殊な MethodTable として扱われます
  • グローバルポインタの欠落時も安全に処理されるため、古いランタイムバージョンとの互換性も考慮されています
  • テストはデバッガやダンプツール用の AsyncContinuation デバッジー を含みます

#124854 Convert priority 3 MethodDescCallSite calls to UnmanagedCallersOnly

  • 作成者: @steveisok
  • 作成日時: 2026年02月25日 12:48:35(UTC)
  • マージ日時: 2026年03月06日 17:25:07(UTC)
  • ラベル: area-VM-coreclr

概要

MethodDescCallSiteを使用したネイティブからマネージド呼び出しを、UnmanagedCallersOnly属性を使用したリバースP/Invoke呼び出しに変換する優先度3の第1次変更セットです。AppDomain.RaiseExitProcessEvent、AppDomain.OnUnhandledException、RunManagedStartup、ReflectionTypeLoadException/TargetInvocationExceptionコンストラクタなど6つの呼び出しサイトが対象です。

変更内容

  • appdomain.cpp: MethodDescCallSiteをUnmanagedCallersOnlyに変換(4行追加/8行削除)
  • assembly.cpp: RunManagedStartup及び関連呼び出しをリバースP/Invokeに変換(2行追加/6行削除)
  • invokeutil.cpp: Exception生成コード(ReflectionTypeLoadException、TargetInvocationException)をUnmanagedCallersOnlyパターンに変換(11行追加/90行削除)
  • System.Private.CoreLib: マネージド側の[UnmanagedCallersOnly]属性付きラッパーメソッドを追加
  • callhelpers-reverse.cpp: WebAssembly向けリバースP/Invoke呼び出しヘルパーを拡張(99行追加/43行削除)
  • その他: メタシグネチャ、QCall定義、モジュール定義を更新

パフォーマンスへの影響

具体的なベンチマーク数値は記載されていませんが、改善効果としては以下が期待されます:

  • MethodDescCallSiteから直接UnmanagedCallersOnlyへの変換により、呼び出しオーバーヘッドが削減される可能性
  • Exception*アウトパラメータの導入により、例外ハンドリングのコスト最適化
  • invokeutil.cppで90行の削除により、コード複雑度が低減

懸念点: パフォーマンスへの直接的な負の影響は記載されていません。

関連Issue

#123864(親Issueで、MethodDescCallSiteからUnmanagedCallersOnlyへの包括的変換)、#124834(優先度2の先行変換)

その他

  • フォローアップ項目: RunMainInternal内のメインエントリポイント、CustomAttribute_CreateCustomAttributeInstance、CorHost2::ExecuteAssembly、FuncEvalWrapper/DoNormalFuncEvalが残存
  • パターン: [UnmanagedCallersOnly]属性付きマネージドラッパーメソッドとException*アウトパラメータを使用した統一的な変換パターンを採用
  • WebAssembly向けコード(wasm/callhelpers-reverse.cpp)が大幅に拡張されており、クロスプラットフォーム対応の充実が示唆されます

#124720 Expose HTTP.sys kernel response buffering control for HttpListener on Windows

  • 作成者: @karimsalem1
  • 作成日時: 2026年02月22日 07:50:19(UTC)
  • マージ日時: 2026年03月06日 08:16:11(UTC)
  • ラベル: area-System.Net.Http new-api-needs-documentation community-contribution

概要

HttpListener(Windows実装)でHTTP.sys カーネルレスポンスバッファリングを制御するopt-in AppContext スイッチを追加しました。有効化すると、HttpSendHttpResponseHttpSendResponseEntityBody の呼び出しに HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA フラグが設定されます。小バッファサイズでの応答送信時のレイテンシを最大30倍削減します。

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering", true);
using var listener = new HttpListener();
listener.Prefixes.Add("http://localhost:8080/");
listener.Start();

変更内容

  • HttpListener.Windows.cs: AppContext スイッチ設定を読み込む処理を追加(+7行)
  • HttpResponseStream.Windows.cs: レスポンス送信時にバッファリングフラグを適用する処理を追加(+4行)
  • HttpListenerTests.Windows.cs: Windows専用テスト追加(+75行)
  • HttpResponseStreamTests.Windows.cs: Windows専用テスト追加(+248行)
  • HttpResponseStreamTests.cs: 既存Windows専用テストをWindows専用クラスに統合(-110行)
  • テストプロジェクト設定: Windows専用テストファイルをcsprojに追加

パフォーマンスへの影響

改善効果(実測値):

  • エンドツーエンドレイテンシ: 最大30倍削減(32KBバッファで33,911ms → 1,154ms)
  • Write()実行時間: 158,414µs → 4,589µs(32KBバッファで約97%削減)
  • ネットワーク動作: RTT毎の個別パケット送信から、カーネル側でのバッファリングによる大量バースト送信に変更

技術的詳細: カーネルバッファリング無効時、小バッファ書き込みは各Write()呼び出しがTCPセグメントごとにACK待機(RTTアンプリフィケーション)で送信されます。有効時、HTTP.sysがカーネル空間でデータを集約し大量バースト送信することで、ネットワークパイプラインを効率的に活用します。

  • デフォルト動作: 変更なし(後方互換性を完全に維持)
  • 互換性: 新しいAppContextスイッチはopt-inのため、既存コードへの影響なし

関連Issue

#123425

その他

  • 公開API変更: なし(内部実装のみ)
  • テスト戦略: リフレクションを使用してフラグ動作を検証(内部APIのため)
  • テスト整理: Windows専用テストクラスを専用ファイルに統合し、一貫性を向上

#124555 Remove Windows 7 support code from System.Net.Security

  • 作成者: @Copilot
  • 作成日時: 2026年02月18日 14:21:51(UTC)
  • マージ日時: 2026年03月06日 07:46:26(UTC)
  • ラベル: area-System.Net

概要

Windows 7のサポート終了に伴い、System.Net.Securityから Win7固有のコード経路とバージョン判定ロジックを削除するメンテナンスPRです。IsWindowsVersionAtLeast(6, 2)ガード、Win7関連のコメント、デッドコードを削除し、プロダクトコードとテストコード両方をクリーンアップします。

変更内容

  • SslCertificateTrust.cs: IsWindowsVersionAtLeast(6, 2)IsWindows()に置き換え(Win7除外ロジックは不要になったため)、不要なusingディレクティブ削除
  • SslAuthenticationOptions.cs: Pre-Win10でのSSL2/TLS1.2非互換性に関するコメント削除(実装コードは変更なし)
  • ExtendedProtectionPolicy.cs: ExtendedProtectionサポート対象を現在の.NETサポートOS対象に明確化
  • SslStreamPal.Windows.cs: レガシーSchannel認証情報パスのコメント更新(Win10ビルド18836以前対応、Win7ではない)
  • TestConfiguration.cs: ヌル暗号化検出の!PlatformDetection.IsWindows10OrLaterデッドブランチ削除
  • SslStreamSystemDefaultsTest.cs: IsWindows && WindowsVersion >= 10IsWindowsに簡略化
  • SslStreamCredentialCacheTest.cs: Win8の動作変更に関するコメント更新

パフォーマンスへの影響

影響なし。本変更は条件分岐の単純化により、ランタイムの分岐予測効率が微小に向上する可能性がありますが、測定可能なレベルではありません。主な利点はコード複雑性の低減です。

関連Issue

なし

その他

  • 本PRは破壊的変更ではなく、Win7向けビルドは既にサポート対象外のため、後方互換性への影響はありません
  • Schannel認証情報の二重パス実装(SCHANNEL_CRED/UseNewCryptoApi)は保持されます。これはWin10ビルド18836以前(TLS 1.3実装前)対応であり、Win7対応ではありません
  • Copilotによるレビューで、TestConfiguration.csのSupportsNullEncryptionメソッド内のProcess.Start()処理にて、PowerShellコマンド失敗時のエラーハンドリングが不完全である可能性が指摘されています(標準エラーの処理未実装)

#124524 Obsolete Encrypt / Decrypt with fOAEP

  • 作成者: @vcsjones
  • 作成日時: 2026年02月17日 19:00:49(UTC)
  • マージ日時: 2026年03月06日 19:05:37(UTC)
  • ラベル: area-System.Security breaking-change

概要

RSA暗号化のEncryptおよびDecryptメソッドでfOAEPパラメータの使用を非推奨化するPRです。これらのメソッドはRSACryptoServiceProviderクラスに属し、より安全な暗号化スキームの使用を推奨するための廃止予告です。診断コードSYSLIB0096が追加されました。

変更内容

  • Obsoletions.cs: SYSLIB0096診断コードを新規追加
  • RSA関連クラス: Encrypt/Decryptメソッドに[Obsolete]属性を適用
    • Windows実装(RSACryptoServiceProvider.Windows.cs
    • Unix実装(RSACryptoServiceProvider.Unix.cs
  • 参照定義: System.Security.Cryptography.csに非推奨化メソッドの定義を追加
  • テスト: RSACryptoServiceProviderTests.csに非推奨化に関するテストケースを追加
  • ドキュメント: list-of-diagnostics.mdに新しい診断コードを記載

パフォーマンスへの影響

影響なし。これは非推奨化のみで、既存の実装ロジックには変更がありません。

関連Issue

#113616(非推奨化に関する要件を定義するIssue)

その他

この変更は破壊的変更ではなく、非推奨化予告です。既存コードは動作し続けますが、コンパイル時にSYSLIB0096警告が表示されるようになります。fOAEPパラメータを使用するコードは、より安全な暗号化API(例:RSA.EncryptRSAEncryptionPadding)への移行が推奨されます。


目次