Pull Request on 2026年02月18日

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

注意点

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



#124573 Add SHA-384 and SHA-512 hash algorithms to metadata spec

  • 作成者: @tmat
  • 作成日時: 2026年02月18日 22:49:39(UTC)
  • マージ日時: 2026年02月18日 23:06:27(UTC)
  • ラベル: area-Meta

概要

Portable PDB メタデータ仕様にSHA-384およびSHA-512ハッシュアルゴリズムのサポートを追加しました。Portable PDBは.NETアプリケーションのデバッグ情報保存に使用され、Document テーブル内でハッシュアルゴリズムを用いてソースファイルの検証を行います。

変更内容

ファイル 変更内容
docs/design/specs/PortablePdb-Metadata.md SHA-384ハッシュアルゴリズムGUID(d99cfeb1-8c43-444a-8a6c-b61269d2a0bf)を追加
SHA-512ハッシュアルゴリズムGUID(ef2d1afc-6550-46d6-b14b-d70afe9a5566)を追加

パフォーマンスへの影響

仕様の追加のみで、ランタイムの実装変更を含まないため、直接的なパフォーマンスへの影響はありません。SHA-384/512の実装が今後追加される場合、ハッシュ計算時間がSHA-256と比べて増加する可能性がありますが、本変更では実装されていません。

関連Issue

なし

その他

本変更はメタデータ仕様の更新のみで、ランタイム実装の変更は含まれていません。SHA-384/SHA-512のハッシュアルゴリズムサポート機能の実装は、別途のPull Requestで行われる見込みです。


#124543 Fix comment in eng/Versions.props

  • 作成者: @akoeplinger
  • 作成日時: 2026年02月18日 09:21:34(UTC)
  • マージ日時: 2026年02月18日 09:39:16(UTC)
  • ラベル: area-codeflow

概要

eng/Versions.props内の古くなったコメントを更新するためのマイナー修正です。最近の.NET 11 SDKバージョンバンプ中に廃止されたコメントをバージョンに依存しない汎用的な説明に変更し、将来のメンテナンス負荷を軽減します。

変更内容

ファイル 変更内容
eng/Versions.props ハードコードされたマニフェストトランスポートMSBuildプロパティ名をコメントから削除し、汎用的な説明に置き換え

パフォーマンスへの影響

影響なし (コメント行のみの変更であり、ビルドプロセスやランタイムパフォーマンスへの影響はありません)

関連Issue

記載情報なし

その他

この変更はバージョン管理ファイルのメタデータ修正であり、ビルドシステムの将来的な保守性を向上させることが目的です。SDKバージョンが今後更新される場合、コメント自体を修正する必要がなくなります。


#124542 Revert "Re-enable SslStreamTlsResumeTests.ClientDisableTlsResume_Succeeds"

  • 作成者: @rzikm
  • 作成日時: 2026年02月18日 09:17:58(UTC)
  • マージ日時: 2026年02月18日 12:01:15(UTC)
  • ラベル: area-System.Net.Security

概要

TLS再開機能に関するテスト ClientDisableTlsResume_Succeeds を再度無効化するリバートです。Windows 2022 と Windows Nano プラットフォームでテスト失敗が発生しているため、[ActiveIssue] 属性を追加して Windows での実行をスキップします。

変更内容

  • ファイル: src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamAllowTlsResumeTests.cs
    • ClientDisableTlsResume_Succeeds テストメソッドに [ActiveIssue] 属性を追加
    • Issue #103449 にリンク

パフォーマンスへの影響

影響なし

関連Issue

  • dotnet/runtime#124463(前回のテスト再有効化PR)
  • Issue #103449(テスト失敗の原因となる既知問題)

その他

このリバートはプラットフォーム固有の問題に対応した一時的な対応です。Windows 2022 と Windows Nano での TLS セッション再開機能の動作に関する問題が完全に解決されるまで、これらのプラットフォームではテストがスキップされます。


#124538 [mono][interp] Add missing intrinsic for Volatile.ReadBarrier/WriteBarrier

  • 作成者: @BrzVlad
  • 作成日時: 2026年02月18日 08:07:11(UTC)
  • マージ日時: 2026年02月18日 11:26:21(UTC)
  • ラベル: area-Codegen-Interpreter-mono

概要

Mono インタプリタで System.Threading.Volatile.ReadBarrier()System.Threading.Volatile.WriteBarrier() の intrinsic サポートを追加したバグ修正です。従来はこれらのメソッドが intrinsic スタブとしてインタプリタで実行されると、再帰的に自身を呼び出してスタックオーバーフローを引き起こしていました。本修正により、既存のメモリバリア opcode を emitすることで問題を解決します。

// 修正前: スタックオーバーフローが発生
Volatile.ReadBarrier();  // インタプリタ上で無限再帰

// 修正後: 適切にメモリバリアが実装される
Volatile.ReadBarrier();  // メモリバリア opcode として実行

変更内容

  • src/mono/mono/mini/interp/transform.c: Volatile.ReadBarrier()Volatile.WriteBarrier() に対する interpreter intrinsic マッピングを追加(3行追加)
  • 実装として、既存のインタプリタメモリバリア opcode を emitすることで、スタックオーバーフロー問題を解決

パフォーマンスへの影響

改善: スタックオーバーフロー防止により、Mono インタプリタ実行時における Volatile.ReadBarrier/WriteBarrier の呼び出しが正常に動作するようになります。パフォーマンス低下はなく、むしろクラッシュを防ぐ重要な修正です。

関連Issue

#124538

その他

  • 修正は Mono インタプリタ(JIT コンパイラ未使用時の実行エンジン)に限定される変更
  • 実装はシンプルに full memory barriers を使用
  • AOT コンパイル時や JIT 使用時の動作には影響なし

#124536 Avoid resolving direct awaits to thunks (IL scanner part)

  • 作成者: @MichalStrehovsky
  • 作成日時: 2026年02月18日 03:49:39(UTC)
  • マージ日時: 2026年02月18日 11:20:04(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

NativeAOT環境でランタイム非同期処理を有効にした場合の不要な非同期サンク生成を回避する最適化です。IL scannerは直接呼び出しされるTask戻り値メソッドに対して非同期バリアント サンクの生成をスキップし、JIT オーバーヘッドを削減します。

// 直接呼び出しの検出により、不要なthunk生成を回避
if (IsCallEffectivelyDirect(method))
{
    // async variant resolution をスキップ
}

変更内容

  • MethodExtensions.cs: IsCallEffectivelyDirect() 拡張メソッドを新規追加(22行)
  • CorInfoImpl.cs: 重複する private メソッドを削除し、拡張メソッドに統一(-23行)
  • ILImporter.Scanner.cs: IL scanner に直接呼び出しの非同期サンク回避ロジックを追加(+22行)
  • CorInfoImpl.RyuJit.cs: 拡張メソッド使用へ更新(-1行)
  • テストファイル: 静的仮想インターフェースメソッドの非同期ケースを検証するテストを追加

パフォーマンスへの影響

改善点

  • 不要な非同期バリアント サンク生成を排除することで、AOT コンパイル時間を短縮
  • ネイティブコード生成の最適化により、実行時の間接呼び出しオーバーヘッド削減
  • メモリフットプリント削減(サンク用コード領域が不要)

対象シナリオ: NativeAOT で RuntimeFeature.IsAsyncEnabled が有効な場合に限定

関連Issue

#124283 - 直接 await 呼び出しのサンク回避に関する元の最適化 #124536 - 本 PR(IL scanner 部分の実装)

その他

  • コード品質向上: IsCallEffectivelyDirect を共通拡張メソッドに統一し、複数箇所での重複実装を排除
  • 静的仮想インターフェースメソッドの非同期処理を新規テストで検証(outerloop 失敗の回帰防止)

#124503 JIT: Disqualify inlinees using AsyncSuspend intrinsic

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月17日 09:59:46(UTC)
  • マージ日時: 2026年02月18日 17:50:20(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラがAsyncSuspendイントリンシックを使用するメソッド(例:AsyncHelpers.Await)をインライン化しないようにする変更です。最近のインライン化改善により、これらのメソッドがインライン候補になってしまいましたが、インライン化するとAsyncメカニズムが破壊されるため、早期に除外する必要があります。

変更内容

  • src/coreclr/jit/inline.def: ASYNC_SUSPENDという新しい致命的なインライン観測(FATAL inline observation)を追加
  • src/coreclr/jit/importercalls.cpp: イントリンシックインポーター内に、AsyncSuspendを使用するメソッドをインライン不可としてマークする検出ロジックを追加

パフォーマンスへの影響

影響なし。むしろこの変更により、不適切なインライン化による潜在的なランタイムエラーを防止します。AsyncSuspendイントリンシックを使用するメソッドがインライン化されると、呼び出し元が適切な継続(continuation)を作成できなくなり、Asyncメカニズムが機能しなくなるため、この制御は機能的に必須です。

関連Issue

なし

その他

この変更は防御的な修正であり、AsyncSuspendイントリンシックを含むメソッドの不適切なインライン化を早期の導入フェーズで防止します。これはランタイムの正確性(correctness)に関わる重要な修正です。


#124501 Support Profile Optimization for single file deployment

  • 作成者: @FixBo
  • 作成日時: 2026年02月17日 09:41:33(UTC)
  • マージ日時: 2026年02月18日 17:24:44(UTC)
  • ラベル: area-VM-coreclr community-contribution

概要

単一ファイル展開(Single File Deployment)時のProfile Optimization機能において、ファイルパスがnullになることですべてのモジュールがスキップされていた問題を修正しました。この修正により、単一ファイル形式で配布されたアプリケーションでもプロファイル最適化の恩恵を受けられるようになります。

変更内容

  • src/coreclr/vm/multicorejitplayer.cpp (+1/-1)
    • ファイルパスがnullの場合の処理を修正し、単一ファイル展開時にモジュールが不適切にスキップされる問題を解決

パフォーマンスへの影響

改善点:単一ファイル展開されたアプリケーションでProfile Optimizationが正常に動作するようになり、起動時間やスループット面での最適化が可能になります。

関連Issue

#108270 - Profile Optimizationが単一ファイル展開で機能していない問題

その他

最小限の変更(1行追加/削除)で問題が解決されており、既存の処理フローへの影響は限定的と考えられます。単一ファイル展開はWindows App SDK、MAUI、その他の最新の.NETアプリケーション配布形式で使用されるため、実用的な改善といえます。


#124497 Fix Optimization Profile read

  • 作成者: @FixBo
  • 作成日時: 2026年02月17日 04:43:35(UTC)
  • マージ日時: 2026年02月18日 17:26:26(UTC)
  • ラベル: area-VM-coreclr community-contribution

概要

Optimization Profileの読み込み処理でバグを修正しました。fread関数の戻り値を正しく処理していなかった問題を解決しています。freadは読み込んだバイト数ではなく要素数を返すため、その解釈を修正しています。

変更内容

  • src/coreclr/vm/multicorejitplayer.cpp: Optimization Profile読み込み処理を修正(+1/-1行)
    • freadの戻り値判定ロジックを修正し、要素数を正しく検証するように変更

パフォーマンスへの影響

直接的なパフォーマンス影響は軽微と考えられます。ただし、この修正により、Optimization Profileが不正に読み込まれる問題が回避され、JITコンパイル最適化プロファイルの正確な処理が保証されるようになる可能性があります。

関連Issue

なし

その他

  • 影響範囲: CoreCLR VM の MultiCore JIT プレイヤー機能に関連する変更です
  • 技術的背景: freadが返す値は「読み込んだ要素の個数」(引数nmembで指定されたサイズ単位の個数)であり、バイト数ではありません。この誤解によって、Optimization Profile読み込み時の検証ロジックが不正に動作していた可能性があります
  • 互換性: 内部実装の修正であり、公開APIへの影響はありません

#124485 Fix thread safety in SafeEvpPKeyHandle.DuplicateHandle

  • 作成者: @Copilot
  • 作成日時: 2026年02月16日 22:43:40(UTC)
  • マージ日時: 2026年02月18日 18:40:41(UTC)
  • ラベル: area-System.Security

概要

SafeEvpPKeyHandle.DuplicateHandle()のスレッド安全性問題を修正しました。複数スレッドが同時にDuplicateHandle()を呼び出している間に別スレッドがDispose()を実行すると、ハンドルフィールドがゼロにされ、結果として無効な値を持つ未解放のハンドルが返される競合状態が発生していました。

// 修正前: 競合状態が発生する可能性
IntPtr handle = this.handle;  // Dispose()で0にされる可能性

// 修正後: DangerousAddRef/DangerousReleaseで保護
bool addedRef = false;
try
{
    DangerousAddRef(ref addedRef);
    IntPtr handle = this.handle;  // 安全に読み取り
}
finally
{
    if (addedRef)
    {
        DangerousRelease();
    }
}

変更内容

  • SafeEvpPKeyHandle.OpenSsl.cs: DuplicateHandle()メソッドをDangerousAddRef/DangerousReleaseで保護。UpRefEv​pPkeyとハンドルコピー操作の間にDispose()が介入できないようにしました。
  • SafeEvpPKeyHandleTests.cs: 競合条件の回帰テストを追加。DuplicateHandle()Dispose()を1000回反復して並行実行し、ハンドルが正しく処理されることを検証します。

パフォーマンスへの影響

影響なし。DangerousAddRef/DangerousReleaseは参照カウント操作で軽量です。むしろスレッド競合による不定挙動を排除することで、予測可能性が向上します。

関連Issue

#124484 (SafeEvpPKeyHandle.DuplicateHandleのスレッド安全性) #116307 (マーシャリング時にハンドルがNULLになる問題の原因)

その他

レビュー対応により最終的にDangerousAddRef/DangerousReleaseアプローチに統一されました。全テスト1867個がパスしています。


#124479 Quote a few cmake commands to allow spaces

  • 作成者: @am11
  • 作成日時: 2026年02月16日 21:11:00(UTC)
  • マージ日時: 2026年02月18日 00:43:07(UTC)
  • ラベル: area-Infrastructure-coreclr community-contribution

概要

CMakeビルドスクリプトで複数のコマンドをquote処理することで、パスやプロパティに含まれるスペースを適切に処理できるようにしました。これにより、ファイルパスにスペースを含む環境でのビルド失敗を防止します。

変更内容

  • eng/native/functions.cmake (+14/-14)

    • CMakeコマンド引数をquoteで囲み、スペースを含むパスの処理を改善
  • src/coreclr/clrdatadescriptors.cmake (+1/-1)

    • 同様にquote処理を追加してスペース対応を強化

パフォーマンスへの影響

影響なし (CMakeスクリプトの構文レベルの変更であり、ランタイムパフォーマンスへの影響はありません)

関連Issue

なし

その他

本変更はビルド環境の堅牢性向上を目的としています。CMakeコマンドのquote処理により、インストールパスやディレクトリ名にスペースを含む環境でのビルド成功率が向上します。特に、Windows環境や共有ネットワークドライブなどでのビルドシナリオで重要な修正です。


#124472 JIT: Handle LCL_ADDR in TreeLifeUpdater

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月16日 16:32:38(UTC)
  • マージ日時: 2026年02月18日 16:20:06(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT コンパイラの TreeLifeUpdaterLCL_ADDR(ローカル変数のアドレス)ノードの生存期間追跡を改善しました。これまで GTF_VAR_DEATH フラグが LCL_ADDR ノードで処理されていなかったため、非同期変換時にこれらの変数が不必要に生きているものと判定されていました。この修正により、より正確な変数生存期間分析が可能になります。

変更内容

  • treelifeupdater.cppLCL_ADDR ノードに対する GTF_VAR_DEATH フラグの処理を追加
  • treelifeupdater.hTreeLifeUpdater クラスの定義を更新
  • async.cpp, codegencommon.cpp, copyprop.cpp:各ファイルで TreeLifeUpdater 関連の処理を微調整

パフォーマンスへの影響

直接的なパフォーマンス改善は報告されていません。ただし、変数生存期間の分析精度が向上することで、レジスタ割り当てやデッドコード削除などの最適化がより効果的に機能する可能性があります。この変更は保守的な判定を改善するもので、負の影響は想定されません。

関連Issue

なし

その他

  • 複数のJITコンポーネント(async変換、コード生成、コピー伝播最適化)に関連した変更であり、JITバックエンドの信頼性向上を目的としています
  • 広範にレビューされており、JIT最適化の正確性を高める重要な修正として判定されています

#124456 [release/8.0-staging] Update dependencies from dotnet/hotreload-utils

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年02月16日 09:29:07(UTC)
  • マージ日時: 2026年02月18日 01:13:16(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet/hotreload-utilsリポジトリからの依存関係を更新するMaestroによる自動更新PRです。Microsoft.DotNet.HotReload.Utils.Generator.BuildToolを8.0.0-alpha.0.26076.2から8.0.0-alpha.0.26116.3にアップデートしています。

変更内容

  • eng/Version.Details.xml: Microsoft.DotNet.HotReload.Utils.Generator.BuildToolのバージョン情報を更新(+2/-2行)
  • eng/Versions.props: ビルドプロパティのバージョン参照を更新(+1/-1行)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRはMaestroボット(dotnet-maestro[bot])による自動依存関係更新PRです
  • release/8.0ブランチのhotreload-utilsリポジトリからの更新で、2026年2月16日にビルドされたバージョンが取り込まれています
  • レビュワーはsteveisokです

#124451 Add more null checks to request.cpp

  • 作成者: @leculver
  • 作成日時: 2026年02月16日 01:42:06(UTC)
  • マージ日時: 2026年02月18日 02:07:36(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

Linux上の診断ツール(clrmd、sos、dotnet-dump analyze)におけるクラッシュを修正するため、request.cppにnullチェック処理を追加しました。DAC(Data Access Component)への呼び出しでnull値が渡された場合、SIGSEGVで強制終了するのではなく適切に処理するようになります。

変更内容

src/coreclr/debug/daccess/request.cpp

  • nullチェック処理を複数箇所に追加(+21行)
  • 古いバージョンの診断ツールがnull値で呼び出してきた場合に対応

パフォーマンスへの影響

影響なし。本変更はエラーハンドリングの改善であり、通常の実行パス上のパフォーマンスに影響を与えません。

関連Issue

https://github.com/dotnet/diagnostics/issues/5632

その他

  • この修正は、診断ツール側の不正な呼び出しの修正を補完するものです
  • Linux環境では例外がスワローされないため、nullチェックによるクラッシュ防止が重要です
  • 古いバージョンの診断ツールとの互換性維持を目的とした防御的プログラミングです

#124411 Fix the type of exception thrown when decoding bad headers

  • 作成者: @bartonjs
  • 作成日時: 2026年02月14日 00:04:15(UTC)
  • マージ日時: 2026年02月18日 19:18:00(UTC)
  • ラベル: area-System.Security

概要

CoseMessage.DecodeSign1CoseMessage.DecodeMultiSignメソッドで、内部検証時にArgumentExceptionが漏洩していた問題を修正。ドキュメントに定義された「デコード失敗時はCryptographicExceptionを投げる」という契約を守るようにしました。また、クリティカルヘッダ検証で不定長CBORアレイのサポートも追加されています。

変更内容

  • CoseMessage.cs: DecodeBucketメソッドの例外処理を修正し、検証時のArgumentExceptionCryptographicExceptionでラップ。CBOR配列/マップの解析を定長・不定長両方に対応させました。(+47/-9行)
  • CoseMessageTests.DecodeSign1.cs: クリティカルヘッダ検証エラーでCryptographicExceptionが投げられることを検証するテストを新規追加(+125行)
  • CoseMessageTests.DecodeMultiSign.cs: マルチサイン メッセージのクリティカルヘッダ検証エラーテストを新規追加(+126行)
  • CoseMessageTests.Sign.CustomHeaderMaps.cs: 既存テストを定長・不定長両方のクリティカルヘッダアレイに対応するよう拡張(+35/-20行)

パフォーマンスへの影響

影響なし。本修正は例外処理とCBOR解析ロジックの修正のみで、パフォーマンスに関連する変更はありません。

関連Issue

なし

その他

  • 互換性への影響: この修正は破壊的変更ではなく、むしろドキュメント通りの動作に修正するものです。既存コードがArgumentExceptionをキャッチしていた場合は、今後CryptographicExceptionをキャッチする必要があります。
  • テストカバレッジ: 251行のテストが新規追加され、例外型の正確性と不定長CBOR対応が十分に検証されています。

#124347 [browser] no sockets

  • 作成者: @pavelsavara
  • 作成日時: 2026年02月12日 15:32:42(UTC)
  • マージ日時: 2026年02月18日 17:47:30(UTC)
  • ラベル: arch-wasm area-System.Net.Sockets os-browser

概要

ブラウザプラットフォーム向けにSystem.Net.Socketsの機能をサポート対象外化するPRです。ブラウザ環境ではソケット機能が利用できないため、すべてのメンバーでPlatformNotSupportedExceptionをスロー するよう実装しています。また、SocketAddressPal.Browser.csを新規追加し、Windows実装に類似した浅い実装を提供しています。

// ブラウザ環境での動作例
try 
{
    var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
}
catch (PlatformNotSupportedException)
{
    // ブラウザ環境では PNSE がスロー
}

変更内容

  • SocketAddressPal.Browser.cs: ブラウザ向けのソケットアドレス実装を新規追加(72行)
  • System.Net.Sockets.csproj: ブラウザターゲット向けビルド定義を更新
  • System.Net.Primitives: ブラウザプラットフォーム対応のテストプロジェクト設定を追加
  • pal_networking_browser.c: ブラウザ環境向けネットワーク機能スタブ実装(551行)
  • pal_interfaceaddresses_browser.c: インターフェースアドレス取得のブラウザ実装(48行)
  • pal_networkstatistics_wasm.c: ネットワーク統計情報のWASM実装(89行)
  • CMakeLists.txt: HAVE_SYS_SOCKET_H フラグによるソケットAPI関連コードの条件付きコンパイル設定
  • Mono profiler: ソケット関連ヘッダーのガード追加

パフォーマンスへの影響

影響なし。ブラウザ環境ではそもそもソケット機能が利用不可のため、パフォーマンス上の考慮事項はありません。

関連Issue

  • #122506(親Issue)
  • #123962(前回の関連PR)

その他

注意点: Copilotの指摘通り、src/mono/mono/mini/cfgdump.cにおいてnetinet/in.harpa/inet.hのインクルードがまだ無条件であり、HAVE_SYS_SOCKET_Hでガードされていないソケット関連ヘッダーがあります。これらの追加ガードが必要な可能性があります。


#124271 Add ProcessStartOptions class with platform-aware path resolution

  • 作成者: @Copilot
  • 作成日時: 2026年02月11日 13:33:48(UTC)
  • マージ日時: 2026年02月18日 10:23:57(UTC)
  • ラベル: area-System.Diagnostics.Process

概要

ProcessStartOptions クラスを新たに追加し、プロセス起動時の実行ファイルパス解決をプラットフォーム対応で明示的に行えるようにしました。Windows では .exe 拡張子の自動追加、System32 ディレクトリの検索、PATH 環境変数の参照を実装し、Unix では PATH のみを検索します。遅延初期化されたコレクション(Arguments、Environment、InheritedHandles)を提供し、ProcessStartInfo より安全で制御性の高い代替手段となります。

変更内容

  • ProcessStartOptions.cs(新規、255行): 実行ファイルパス解決とプロセス設定を提供するパブリック API

    • コンストラクタで FileNotFoundException を発生(ファイルが見つからない場合)
    • プロパティ:FileNameArgumentsEnvironmentWorkingDirectoryInheritedHandlesKillOnParentExitCreateNewProcessGroup
  • ProcessUtils.cs(新規、32行): 共有ロジック実装

    • FindProgramInPath() メソッド(プラットフォーム共通)
  • ProcessUtils.Windows.cs(新規、15行): Windows 固有実装

    • IsExecutable() プライベートメソッド(File.Exists に委譲)
  • ProcessUtils.Unix.cs(新規、72行): Unix 固有実装

    • IsExecutable() で実行権限を検証
  • Process.Unix.cs(変更): 86行削除、重複していた Process.ResolvePath ロジックを削除

    • ProcessStartOptions.ResolvePath を呼び出すように変更
  • ref/System.Diagnostics.Process.cs(変更): パブリック API 定義を追加(11行)

  • テスト(新規、547行):

    • ProcessStartOptionsTests.cs:基本テスト(179行)
    • ProcessStartOptionsTests.Windows.cs:Windows 固有テスト(199行)
    • ProcessStartOptionsTests.Unix.cs:Unix 固有テスト(169行)
    • 25 個のユニットテスト、遅延初期化・パス解決・プラットフォーム固有の動作・エラーケースをカバー
  • Environment.Windows.cs(変更): Windows ディレクトリをキャッシュする機構を追加(16行追加)

パフォーマンスへの影響

  • 遅延初期化: ArgumentsEnvironmentInheritedHandles は初回アクセス時にのみメモリ割り当て、通常の環境変数不要なケースでメモリ効率が向上します。
  • Windows ディレクトリキャッシュ: s_cachedWindowsDirectory でシステムディレクトリ取得結果をキャッシュし、複数インスタンス生成時の重複呼び出しを削減。
  • パス検索の効率化: PATH 検索アルゴリズムは既存 Process.ResolvePath と同等で、重複ロジックを排除したため保守性向上、性能低下なし。

関連Issue

なし

その他

  • 互換性: 破壊的変更なし。既存 ProcessStartInfo は維持される新規 API です。
  • ローカライズ対応: エラーメッセージは SR.FileNotFoundResolvePath で多言語対応。
  • パス解決ルール:
    • Windows: .exe

#124223 [release/10.0] fix Vector2/3 EqualsAny

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年02月10日 14:31:19(UTC)
  • マージ日時: 2026年02月18日 18:36:50(UTC)
  • ラベル: Servicing-approved area-System.Numerics

概要

Vector2/Vector3のEqualsAnyメソッドが非決定的な結果を返す問題を修正しました。新しく公開されたAPIで、加速化された比較操作時に無効な要素が誤って含まれる可能性がありました。既存の一元化されたヘルパーメソッドを使用するよう修正し、一貫性のある処理を実現しました。

// 修正前:独立した実装
// 修正後:一元化されたヘルパーメソッドを使用
public bool EqualsAny(Vector2 other) => EqualsAnyHelper(this, other);

変更内容

  • Vector2.cs (System.Private.CoreLib)

    • EqualsAnyメソッドの実装を既存のヘルパーメソッドを使用する形に修正
  • Vector3.cs (System.Private.CoreLib)

    • EqualsAnyメソッドの実装を既存のヘルパーメソッドを使用する形に修正
  • Vector2Tests.cs (System.Numerics.Vectors)

    • EqualsAnyメソッドの動作検証テストを84行追加
  • Vector3Tests.cs (System.Numerics.Vectors)

    • EqualsAnyメソッドの動作検証テストを91行追加

パフォーマンスへの影響

影響なし。修正はコードジェネレーションの正確性を改善するもので、パフォーマンス特性の変化はありません。一元化されたヘルパーメソッドの使用により、最適化は既に確立された形で適用されます。

関連Issue

#123586 で報告。#123594 のrelease/10.0へのバックポート。

その他

  • リスク評価:Low - これらは新しいAPIで、既存の実装パターンに統一するための修正のため、回帰リスクは低い
  • テスト戦略 - 明示的なテストケースと手動によるコードジェネレーション検証を実施済み
  • 破壊的変更なし(新しいAPIの内部実装修正のため)

#124202 Remove INodeWithSize interface, use IMAGE_REL_SYMBOL_SIZE relocation, and restructure ModuleInfoRow

  • 作成者: @Copilot
  • 作成日時: 2026年02月09日 22:10:47(UTC)
  • マージ日時: 2026年02月18日 00:32:17(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

このPRはNativeAOTの依存性分析フレームワークを簡素化するもので、INodeWithSizeインターフェース廃止し、IMAGE_REL_SYMBOL_SIZEリロケーションによるモジュールセクションサイズ報告に統一します。同時にModuleInfoRow ABI構造を{ SectionId, Length, Start }に再構成し、ランタイムがLengthフィールドを直接参照できるようにしました。

変更内容

削除された要素:

  • INodeWithSizeインターフェース実装と各ノードの手動_sizeプロパティ追跡(30以上のDependencyAnalysisノードから削除)
  • ModuleInfoFlags列挙型(マネージド・ネイティブの両方)
  • HasEndPointerフラグと古い長さ計算ロジック

追加・更新された要素:

  • ReadyToRunHeaderNodeIMAGE_REL_SYMBOL_SIZEリロケーションでセクション長を自動計算
  • ModuleInfoRow:新しい3フィールドレイアウト(SectionIdLengthStart
  • ObjectWriter.cs:オフセット0シンボルのサイズ記録を常に有効化
  • DehydratedDataNode:fixupカウントの代わりに脱水データ長をエンコード

39ファイル変更(主にDependencyAnalysisノード群、TypeManager、ObjectWriter)

パフォーマンスへの影響

改善点:

  • 手動サイズ追跡の廃止により、コンパイラ複雑度が低下
  • IMAGE_REL_SYMBOL_SIZEリロケーション活用により、バイナリエミッション最適化が可能

注記: 実測パフォーマンスベンチマーク値は提供されていませんが、機械的な構造簡素化のためランタイムオーバーヘッド変化は最小限と予想されます。

関連Issue

なし

その他

  • 互換性: ModuleInfoRowレイアウト変更は、NativeAOTランタイムとコンパイラの両者を同時更新するため、バイナリ互換性の破壊はありません
  • コード品質: 機械的削除後に単一ブランク行復元を実施し、コードスタイルを保持

#124166 [release/10.0] Update dependencies from dotnet/xharness

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

概要

dotnet/xharness の依存ライブラリを更新するプル リクエストです。Microsoft.DotNet.XHarness.CLI、Microsoft.DotNet.XHarness.TestRunners.Common、Microsoft.DotNet.XHarness.TestRunners.Xunit が 11.0.0-prerelease.26064.3 から 11.0.0-prerelease.26114.1 にアップデートされます。これは Maestro による自動依存更新です。

変更内容

  • .config/dotnet-tools.json - dotnet ツール設定の更新
  • eng/Version.Details.props - バージョン詳細情報の更新(3行変更)
  • eng/Version.Details.xml - バージョン詳細情報の定義更新(6行変更)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他


#124117 Add parameterized CRC-32 and CRC-64

  • 作成者: @bartonjs
  • 作成日時: 2026年02月07日 00:58:35(UTC)
  • マージ日時: 2026年02月18日 23:02:14(UTC)
  • ラベル: area-System.IO.Hashing

概要

CRC-32とCRC-64の汎用パラメータ化実装が追加されました。既存の最適化済み実装(Crc32Crc64)とCRC-32/C(x86/ARM intrinsics対応)はそのまま利用し、その他のパラメータセットはバイト単位のテーブルルックアップで実装されています。汎用ベクトル化は今後の改善予定とされています。

// パラメータセット指定によるCRC計算の使用例
var parameterSet = Crc32ParameterSet.Crc32; // 標準CRC-32
var crc = new Crc32(parameterSet);
crc.Append(data);
var hash = crc.GetCurrentHashAsUInt32();

変更内容

  • 公開API拡張: Crc32ParameterSetCrc64ParameterSetクラスを新規追加し、既知パラメータセット(Crc32、Crc32C、Crc64、NVMe等)を定義
  • 既存クラスの拡張: Crc32Crc64にパラメータセット対応コンストラクタを追加
  • 実装分割: パラメータセット定義(.WellKnown.cs)とテーブル生成(.Table.cs)をそれぞれ分離
  • 参照API更新: System.IO.Hashing.csに新規型定義を追加
  • 広範なテスト追加: 各パラメータセット(Crc32C、Custom、NVMeなど)に対応した専用テストスイートを実装

パフォーマンスへの影響

改善点:

  • Crc32パラメータセット使用時は既存の最適化済み実装を継続利用
  • CRC-32/C(パラメータセット指定時)はx86/ARM intrinsics により高速化を維持

懸念点:

  • その他パラメータセットはバイト単位のテーブルルックアップ実装のため、汎用ベクトル化実装との比較でパフォーマンス改善の余地あり(ロードマップに記載)
  • メモリ使用量はパラメータセットごとのテーブル保有により若干増加

関連Issue

#123164、#85222、#78063

その他

  • 24の新規テストファイル/テストスイート追加により、複数パラメータセット組み合わせでの網羅的検証を実施
  • 将来の最適化(汎用ベクトル化)を見据えた拡張可能な設計となっている
  • 公開APIの破壊的変更はなく、既存のCrc32/Crc64の使用方法は変わらない

#123824 [Android CoreCLR] Log managed callstacks on native crash

  • 作成者: @mdh1418
  • 作成日時: 2026年01月30日 23:27:17(UTC)
  • マージ日時: 2026年02月18日 16:58:30(UTC)
  • ラベル: area-VM-coreclr os-android

概要

Android CoreCLR でネイティブクラッシュ時にマネージドコールスタックをログに出力する機能を追加しました。Android では CreateDump が利用できないため、クラッシュレポートとしてマネージドフレームを含むスタックトレースを ADB ログに記録します。これにより、ダンプなしでもクラッシュの原因究明が容易になります。

// 例:マネージド例外時のログ出力
// "02-10 13:09:24.654 22261 22275 E DOTNET  : Unhandled exception. System.InvalidOperationException..."
// "02-10 13:09:24.654 22261 22275 E DOTNET  :    at Program.Level3()"
// のようにスタックトレースが記録される

変更内容

  • src/coreclr/pal/inc/pal.h (+12): PROCLogManagedCallstackForSignal() 関数宣言を追加
  • src/coreclr/pal/src/include/pal/process.h (+14): プロセス関連のヘッダー定義を拡張
  • src/coreclr/pal/src/thread/process.cpp (+61): PROCLogManagedCallstackForSignal() の実装、マネージドスタックのログ出力処理を追加
  • src/coreclr/pal/src/exception/signal.cpp (+6): シグナルハンドラーからのコールスタック記録呼び出しを追加
  • src/coreclr/vm/eepolicy.cpp (+17): PROCCreateCrashDumpIfEnabled のコールサイトで新関数を呼び出す処理を追加
  • src/coreclr/vm/eepolicy.h (+4): 関連する宣言を追加
  • src/coreclr/vm/ceemain.cpp (+4): 初期化処理の変更

パフォーマンスへの影響

影響なし

本機能はクラッシュ時のみ実行されるため、通常の実行パフォーマンスへの影響はありません。クラッシュ時のログ出力処理により若干のオーバーヘッドが生じますが、プロセス終了前の処理のため実行時のパフォーマンス指標には影響しません。

関連Issue

なし

その他

  • Android 専用機能: PROCLogManagedCallstackForSignal は Android 専用で、他のプラットフォームでは呼び出されません
  • スタックログの対象: 未処理マネージド例外、FailFast、ネイティブシグナル(SIGABRT、SIGSEGV など)、スタックオーバーフローなど複数のクラッシュシナリオに対応
  • 重複排除: PROCAbort の一部コールサイトでは呼び出されない設計により、スタックログの重複を避けています
  • 制限事項: PROCAbort 経由の場合は、他の経路でスタック記録されるため本機能は呼び出されません(例:ハンドルされない例外の初期ログ)

#122396 [release/8.0-staging] Update dependencies from dotnet/arcade

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2025年12月10日 18:00:39(UTC)
  • マージ日時: 2026年02月18日 13:14:20(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet/arcadeリポジトリからの依存関係更新です。Arcade SDKおよび関連するビルドタスク・ツールを8.0.0-beta.25562.3から8.0.0-beta.25611.2へ更新しました。この更新には、ビルド、パッケージング、テスト、コード分析、APIドキュメント生成など、.NETランタイムのビルドプロセス全体に関わる17個のNuGetパッケージが含まれます。

変更内容

  • eng/Version.Details.xml: 17個のArcadeパッケージのバージョン情報を更新
  • eng/Versions.props: バージョン変数の更新(27行追加/-19行削除)
  • global.json: .NET SDKおよび関連ツールバージョンの更新
  • eng/common/: ビルドスクリプト、PowerShellスクリプト、Azure Pipelinesテンプレートの複数箇所でバージョン参照を更新
    • post-build、source-build、source-index、NuGet検証、SDL実行などのパイプライン処理に関連
    • tools.ps1、nuget-verification.ps1、post-build-utils.psなどのビルドユーティリティを更新

パフォーマンスへの影響

影響なし。このPRは依存関係のバージョン更新のみであり、ランタイムコード自体の変更や機能追加を含みません。

関連Issue

なし

その他

  • 自動生成PR: dotnet-maestroボットによる定期的な依存関係更新です
  • Release/8.0-staging: .NET 8.0リリース用のステージングブランチへの適用です
  • 日時: 2025年12月11日UTC時点のArcadeビルド (#294298) に基づいています
  • 対象: ビルドシステム、テストフレームワーク、API分析ツール、ワークロード管理など、開発環境全体のツールチェーンが対象です

目次