Pull Request on 2026年02月16日

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

注意点

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


目次

  1. #124470 ArrayBufferWriter double grow boundary fix
  2. #124446 Replace MethodDescCallSite with UnmanagedCallersOnly for ObjC interop
  3. #124442 Make report-green.yml run on agentless server job
  4. #124437 Support ISO 8601 24:00:00 (endOfDayFrag) in XSD DateTime validation
  5. #124435 [issue-labeler] Use env var for prediction threshold; default to 0.05
  6. #124432 Fix tree type in impStoreNullableFields and impLoadNullableFields for simds
  7. #124403 Always enable static linking when dynamic code compiled feature is false
  8. #124393 Remove assert from AddNecessaryAsyncReferences
  9. #124388 [HTTP] Fix test race with semaphore.
  10. #124387 Track span.Length's negativity + remove unsound assumption from MergeEdgeAssertions
  11. #124385 [HTTP] Fix ConnectCallback_UseUnixDomainSocket_Success test on Windows
  12. #124384 [HTTP] Remove stale ActiveIssue overrides for #72586
  13. #124373 JIT: Remove dataSection flexible array
  14. #124308 [release/10.0] Fix lookup for current Thread in async signal handler
  15. #124298 [RyuJit/WASM] Implement internal registers
  16. #124287 [release/10.0] Fix incorrect atomic loop optimization when body contains backtracking
  17. #124232 [main] Source code updates from dotnet/dotnet
  18. #124136 [release/10.0] Source code updates from dotnet/dotnet
  19. #121698 Fix FileSystemWatcher macOS start performance
  20. #121343 [release/9.0-staging] Update dependencies from dotnet/roslyn
  21. #120899 [System.DirectoryServices] Fixed possible resource leak
  22. #119644 Fixed excessive capacity allocation in ValueListBuilder<T>
  23. #118932 Improve ImmutableArrayExtensions.SequenceEqual

#124470 ArrayBufferWriter double grow boundary fix

  • 作成者: @sstronin
  • 作成日時: 2026年02月16日 15:57:31(UTC)
  • マージ日時: 2026年02月16日 18:57:52(UTC)
  • ラベル: area-System.Buffers community-contribution

概要

ArrayBufferWriter<T>で現在の容量がint.MaxValue / 2の時に予期しなく再割り当てに失敗するバグを修正しました。バッファが満杯の状態で追加メモリをリクエストすると、オーバーフロー判定が誤った結果になり例外が発生していました。

// 修正前:int.MaxValue / 2 の容量で失敗
var abw = new ArrayBufferWriter<byte>(int.MaxValue / 2);
abw.Advance(abw.Capacity);
abw.GetMemory(1); // throws ArgumentException

変更内容

  • ファイル: src/libraries/Common/src/System/Buffers/ArrayBufferWriter.cs
  • 変更: 容量の成長判定ロジックを修正(1行追加、1行削除)
  • 対象: 内部実装(ArrayBufferWriter<T>クラス)

パフォーマンスへの影響

影響なし。バグ修正による論理的な補正であり、パフォーマンス特性に変更はありません。

関連Issue

なし

その他

  • 発見元: Linux Verification Center (linuxtesting.org)による検証
  • テストの困難性: OutOfMemoryException が発生するため、実質的なテストが困難(メモリ容量を実際に消費する必要がある)
  • 対象範囲: ArrayBufferWriter<T>の境界値処理における厳密性の向上

#124446 Replace MethodDescCallSite with UnmanagedCallersOnly for ObjC interop

  • 作成者: @AaronRobinsonMSFT
  • 作成日時: 2026年02月15日 20:26:31(UTC)
  • マージ日時: 2026年02月16日 16:29:49(UTC)
  • ラベル: area-Interop-coreclr

概要

Objective-C相互運用性の実装において、MethodDescCallSite/CallDescrWorkerを使用した呼び出し機構を、より現代的なUnmanagedCallersOnlyリバースP/Invokeパターンに置き換えました。具体的には、AvailableUnhandledExceptionPropagationInvokeUnhandledExceptionPropagationの2つの関数がこの変更の対象です。

変更内容

  • ObjectiveCMarshal.CoreCLR.cs: マネージ側のP/Invoke定義をUnmanagedCallersOnly対応に更新(+15/-20行)
  • interoplibinterface_objc.cpp: ネイティブ実装の呼び出し機構をCallDescrWorkerからUnmanagedCallersOnlyパターンへ変更(+12/-45行)
  • corelib.h, metasig.h: 関連する型シグネチャ定義を削除・簡略化(各-1~2行)

パフォーマンスへの影響

改善見込みあり。UnmanagedCallersOnlyMethodDescCallSite/CallDescrWorkerよりも軽量な呼び出し規約であり、マネージ-アンマネージ間の境界線を越えるオーバーヘッドが削減される可能性があります。ただし、具体的なベンチマーク数値は提供されていません。

関連Issue

#123864(Priority 4 - ObjC interop)

その他

本変更はObjC相互運用性の優先度4プロジェクトの一部です。UnmanagedCallersOnlyへの移行により、呼び出し規約の標準化と保守性向上が期待できます。変更対象は例外伝播関連の内部機構であり、公開APIへの影響はありません。


#124442 Make report-green.yml run on agentless server job

  • 作成者: @akoeplinger
  • 作成日時: 2026年02月15日 09:43:36(UTC)
  • マージ日時: 2026年02月16日 08:41:39(UTC)
  • ラベル: area-Infrastructure

概要

Azure Pipeline の report-green.yml を、エージェントベースのジョブからエージェントレスサーバージョブに移行しました。ドキュメントのみのPRで成功を報告し、Build Analysis へのハング防止が目的です。従来の PowerShell スクリプトを Delay@1 タスク(遅延0分)に置き換え、CI マシン割り当てを回避して no-op 動作を実現します。

// 変更前: エージェントベースのジョブ
jobs:
  - job: ReportGreen
    pool:
      vmImage: 'windows-latest'
    steps:
      - powershell: # スクリプト処理
      
// 変更後: エージェントレスサーバージョブ
jobs:
  - job: ReportGreen
    pool: server
    steps:
      - task: Delay@1
        inputs:
          delayForMinutes: '0'

変更内容

  • eng/pipelines/report-green.yml:

    • エージェント不要のサーバープール構成に変更
    • PowerShell スクリプト実行を Delay@1 タスク(0分遅延)に置き換え
    • enableTelemetry, helixRepo, enableSBOM, vmImage などの不要な設定を削除
    • 実装行数を 21行に簡略化(+7/-14)
  • docs/README.md:

    • 1行目に末尾空白を追加(意図的でない可能性あり)

パフォーマンスへの影響

改善点: CI マシン割り当てを完全に回避し、リソース消費を削減。エージェントレスジョブの利用により、Azure Pipeline の実行効率が向上し、ビルド待機時間が短縮される可能性があります。

関連Issue

なし

その他

  • 本変更は、ドキュメントのみの変更を含むPRでの Build Analysis ハング防止が主目的
  • docs/README.md への末尾空白追加は無意識的な編集の可能性あり、レビュー時確認推奨

#124437 Support ISO 8601 24:00:00 (endOfDayFrag) in XSD DateTime validation

  • 作成者: @Copilot
  • 作成日時: 2026年02月15日 01:41:34(UTC)
  • マージ日時: 2026年02月16日 15:33:06(UTC)
  • ラベル: area-System.Xml

概要

ISO 8601の24:00:00(endOfDayFrag)表記をXSD DateTime検証で正式にサポートしました。W3C XML Schema 1.1で定義されている24:00:00XmlConvertとXML Schema検証層で受け入れるようになり、2007-04-05T24:00:002007-04-06T00:00:00と解析されます。以前はFormatExceptionが発生していた入力が正常に処理されるようになります。

// 以前: FormatException発生
// 現在: 正常にパース
var dt = XmlConvert.ToDateTime("2007-04-05T24:00:00", XmlDateTimeSerializationMode.RoundtripKind);
// dt == 2007-04-06T00:00:00

変更内容

  • XsdDateTime.cs: ParseTime()hour < 24hour <= 24に変更し、hour=24の場合は分秒以下がゼロであることを検証
  • TryInitiateXsdDateTime(): hour=24の場合は時刻を0に設定し1日加算。オーバーフロー時は例外ではなくfalseを返却
  • s_maxDateTimeTicksForEndOfDay: オーバーフロー判定用の静的キャッシュフィールド追加
  • 新規テストファイル: XmlConvertEndOfDayTests.csに47個のテストケース追加(うるう年、年境界、小数秒、オーバーフロー対応)

パフォーマンスへの影響

改善点: s_maxDateTimeTicksForEndOfDayの静的キャッシュにより、複数回のendOfDay解析時にDateTime.MaxValue.Ticks - TimeSpan.TicksPerDayの再計算が回避されます。

懸念点: hour=24の場合、毎回追加の検証処理(分秒ゼロ判定)が実行されますが、通常のhour≤23の既存パス性能には影響なし。

関連Issue

PR #124142(DateTime/DateTimeOffset/TimeOnlyのISO 8601 24:00サポート基盤)

その他

破壊的変更の可能性: 24:00:00の入力に対してFormatExceptionの発生を期待していたコード、またはスキーマ検証で明示的に24:00:00を拒否していた処理では動作が変化します。ただし24:01:0024:00:01のような無効な形式は引き続き拒否されます。また9999-12-31T24:00:00のようなオーバーフロー候補は引き続きエラーになります。


#124435 [issue-labeler] Use env var for prediction threshold; default to 0.05

  • 作成者: @jeffhandley
  • 作成日時: 2026年02月15日 00:26:34(UTC)
  • マージ日時: 2026年02月16日 15:21:49(UTC)
  • ラベル: area-Meta

概要

issue-labeler の予測閾値を環境変数で設定可能にし、デフォルト値を 0.40 から 0.05 に変更するPR。複数の訓練実行結果から、0.05 の閾値が最も高い正確性(91.91% の一致率)を示し、needs-area-label ラベルが必要なケースを最小化できることが確認されました。ISSUE_LABELER_PREDICTION_THRESHOLD 環境変数で閾値を動的に調整できます。

変更内容

  • .github/workflows/labeler-predict-issues.yml: THRESHOLD を vars.ISSUE_LABELER_PREDICTION_THRESHOLD に変更、デフォルト 0.05
  • .github/workflows/labeler-predict-pulls.yml: THRESHOLD を vars.ISSUE_LABELER_PREDICTION_THRESHOLD に変更、デフォルト 0.05
  • .github/workflows/labeler-train.yml: THRESHOLD を vars.ISSUE_LABELER_PREDICTION_THRESHOLD に変更、デフォルト 0.05
  • .github/workflows/labeler.md: 設定方法のドキュメント追加(8行)

パフォーマンスへの影響

改善点:

  • 予測精度向上: 0.40 (84.59%) → 0.05 (91.91%) で約 7.3% の正確性向上
  • 予測なしのケース削減: 0.40 (11.79%, 5,498件) → 0.05 (0.03%, 13件) に大幅削減
  • 手動ラベル付けの作業量を大幅に減少

トレードオフ:

  • 誤分類率が若干増加: 0.40 (3.62%) → 0.05 (8.06%) ですが、予測スキップ率の改善により全体的には利益

関連Issue

#124435

その他

環境変数 ISSUE_LABELER_PREDICTION_THRESHOLD により、リポジトリごとに閾値を動的に調整可能。この設計により、異なるリポジトリのニーズに応じた最適な設定が実現できます。


#124432 Fix tree type in impStoreNullableFields and impLoadNullableFields for simds

  • 作成者: @EgorBo
  • 作成日時: 2026年02月14日 22:57:14(UTC)
  • マージ日時: 2026年02月16日 13:18:47(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラのimpStoreNullableFieldsimpLoadNullableFields関数において、SIMD型が誤ってTYP_STRUCTとして型付けされていた問題を修正しました。TypeHandleToVarTypeを使用することで、CORINFO_CLASS_HANDLEを適切にTYP_SIMD*型にマッピングするようになります。

変更内容

  • src/coreclr/jit/importer.cpp: impStoreNullableFieldsimpLoadNullableFields関数の型判定ロジックを修正。SIMD型の正確な型付けを実現
  • src/tests/JIT/Regression/JitBlue/Runtime_124425/Runtime_124425.cs: 回帰テストケースを追加(SIMD型を含むnullable構造体の操作を検証)
  • src/tests/JIT/Regression/JitBlue/Runtime_124425/Runtime_124425.csproj: テストプロジェクト設定ファイルを追加

パフォーマンスへの影響

直接的なパフォーマンス改善の記載なし。ただし、正確な型情報の取得により、JITの最適化判断が改善される可能性があります。誤った型付けが原因の潜在的なレジスタアロケーション不最適化やSIMD命令生成の不適切さが改善されると考えられます。

関連Issue

#124425

その他

  • この修正は、nullable構造体の内部にSIMD型フィールドを持つケースに影響します
  • TypeHandleToVarType関数の利用パターンを統一することで、類似の型付けエラーを防止する設計改善になっています

#124403 Always enable static linking when dynamic code compiled feature is false

  • 作成者: @BrzVlad
  • 作成日時: 2026年02月13日 21:22:25(UTC)
  • マージ日時: 2026年02月16日 06:42:14(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

動的コード実行機能が無効な場合、インタープリタライブラリをランタイムに静的リンクする変更です。これにより、FEATURE_DYNAMIC_CODE_COMPILED が false の場合、プラットフォームマニフェストエントリを作成する代わりに、インタープリタライブラリが直接ランタイムに組み込まれます。

// FEATURE_STATICALLY_LINKED の条件を拡張
// Before: モバイルプラットフォーム(WASM, iOS, tvOS, macCatalyst)のみ
// After: FEATURE_DYNAMIC_CODE_COMPILED が false の場合も静的リンク対象に

変更内容

  • src/coreclr/clrfeatures.cmake: FEATURE_STATICALLY_LINKED の条件を拡張(+3/-1)
    • 既存:モバイルプラットフォーム(WASM、iOS、tvOS、macCatalyst)でのみ静的リンク有効
    • 変更後:デスクトッププラットフォームでも FEATURE_DYNAMIC_CODE_COMPILED が false の場合、静的リンクを有効化

パフォーマンスへの影響

静的リンク化により、実行時にマニフェスト経由で動的にライブラリをロードする必要がなくなるため、起動時間の短縮ディスクI/O削減が期待できます。ただし、バイナリサイズは増加する可能性があります。

関連Issue

なし

その他

この変更は CoreCLR の AOT(Ahead-of-Time)コンパイル機能強化の一部と考えられます。Pack ビルドでのマニフェストエントリ管理の簡略化も副次的な効果として含まれています。


#124393 Remove assert from AddNecessaryAsyncReferences

  • 作成者: @jtschuster
  • 作成日時: 2026年02月13日 17:39:43(UTC)
  • マージ日時: 2026年02月16日 23:50:24(UTC)
  • ラベル: area-crossgen2-coreclr runtime-async

概要

ReadyToRun コンパイラの async メソッド処理において、AsyncHelpers への参照が存在しないケースでアサーション失敗が発生していた問題を修正しました。不正確なアサーションを削除し、async メソッドが存在する場合は必ず System.Runtime.CompilerServices.AsyncHelpers を必須メタデータ参照として明示的に追加するように改善しました。

// 修正前:AsyncHelpersが既に参照されていることを前提としていた
Debug.Assert(asyncHelpers != null);

// 修正後:AsyncHelpersが参照されていなくても必須型リストに追加
requiredTypes.Add(asyncHelpers);

変更内容

  • src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs
    • AsyncHelpers 参照の存在を前提とした Debug.Assert を削除
    • System.Runtime.CompilerServices.AsyncHelpersrequiredTypes コレクションに明示的に追加する処理を実装
    • 変更行数:+2/-4(合計6行)

パフォーマンスへの影響

影響なし。本修正は参照解決ロジックの正確性向上であり、ランタイム パフォーマンスへの直接的な影響はありません。

関連Issue

#124389 - このアサーション失敗により outerloop interop テストビルドが失敗していました。

その他

この修正は AOT コンパイル(ReadyToRun)時に async メソッドを含むアセンブリをコンパイルする際の堅牢性を向上させます。特に interop シナリオにおいて、AsyncHelpers への参照が暗黙的でない場合でも正常に動作するようになります。


#124388 [HTTP] Fix test race with semaphore.

  • 作成者: @ManickaP
  • 作成日時: 2026年02月13日 15:30:01(UTC)
  • マージ日時: 2026年02月16日 11:39:04(UTC)
  • ラベル: area-System.Net.Http

概要

HTTPクライアントテストのSend_TimeoutRequestContent_Throwsテストにおけるレース条件を修正しました。サーバー接続がクライアントのタイムアウト前にクローズされることで、テストが不安定になっていた問題を、セマフォベースの同期メカニズムで解決します。

変更内容

  • src/libraries/System.Net.Http/tests/FunctionalTests/HttpClientTest.cs
    • [ActiveIssue]属性を削除(#39056のトラッキング属性)
    • クライアント・サーバー間にセマフォベースの同期ロジックを追加
    • サーバーがクライアントのアサーション完了まで確実に存続するよう制御

パフォーマンスへの影響

影響なし。テストの同期メカニズム追加のため、テスト実行時間がわずかに増加する可能性ありますが、テストコードの変更であり本体パフォーマンスへの影響はありません。

関連Issue

#39056(修正対象のフレーキーテスト追跡用Issue)

その他

このテスト修正により、Send_TimeoutRequestContent_Throwsは以下の期待値を確実に検証できるようになります:

// タイムアウト時に TaskCanceledException が発生し、
// 内部例外として TimeoutException を保持することを確認
catch (TaskCanceledException ex) when (ex.InnerException is TimeoutException)
{
    // 期待通りの動作
}

テストの信頼性向上により、HTTP通信タイムアウト処理の正確な動作保証が実現されます。


#124387 Track span.Length's negativity + remove unsound assumption from MergeEdgeAssertions

  • 作成者: @EgorBo
  • 作成日時: 2026年02月13日 15:20:24(UTC)
  • マージ日時: 2026年02月16日 23:13:20(UTC)
  • ラベル: area-CodeGen-coreclr

概要

このPRは、JIT コンパイラの範囲チェック最適化における不正な仮定を修正します。IsVnCheckedBound の不正な使用(すべての値番号が非負と仮定)を削除し、代わりに span.Length の非負性をアサーション経由で追跡するようにしています。これにより、範囲チェックの削除における誤った最適化を防ぎます。

変更内容

  • assertionprop.cpp: アサーション処理ロジック拡張(+24/-8)
  • compiler.h: VN_Not の単項演算子サポート追加、AssertionDsc のデバッグチェック拡張(+29/-12)
  • rangecheck.cpp: IsVnCheckedBound 仮定の削除(-8)、GetRangeFromAssertions で VNF_Not 対応(+1)

パフォーマンスへの影響

懸念点あり。Diffs によると以下の回帰が予測されています:

  • IsVnCheckedBound ハックの削除による回帰
  • 非昇格 Span が範囲チェック最適化の対象として認識されにくくなる

改善は後続の legacy promotion 廃止時に期待される見込みです。

関連Issue

その他

Copilot レビューの指摘: src/coreclr/jit/rangecheck.cpp:712 で RangeOps::Not() メソッドが存在しないとの警告があります。ただし、実装段階では解決済みの可能性があります。


#124385 [HTTP] Fix ConnectCallback_UseUnixDomainSocket_Success test on Windows

  • 作成者: @ManickaP
  • 作成日時: 2026年02月13日 14:42:22(UTC)
  • マージ日時: 2026年02月16日 20:15:58(UTC)
  • ラベル: area-System.Net.Http

概要

HTTP/2接続の適切なシャットダウン(GOAWAY フレーム伝播)を確保するために、リソース破棄の順序を修正したテスト。HttpClientとハンドラーをGenericLoopbackConnectionより先に破棄することで、Windows環境でのタイミング依存バグを解決します。

変更内容

ファイル: src/libraries/System.Net.Http/tests/FunctionalTests/SocketsHttpHandlerTest.cs

  • ConnectCallback_UseUnixDomainSocket_Success テストメソッドから [ActiveIssue] 属性を削除
  • リソース破棄順序の改善:HttpClient/ハンドラー → GenericLoopbackConnection の順に破棄
  • listenSocket に using 宣言を適用
  • Unix ドメインソケット一時ファイルの cleanup を try/finally ブロックで保護
  • 変更行数:+36/-25

パフォーマンスへの影響

影響なし。本変更はテスト信頼性の向上を目的とした修正であり、パフォーマンスへの直接的な影響はありません。

関連Issue

  • Fixes #44183(HTTP/2シャットダウンタイミング問題)

その他

  • 本修正は dotnet/runtime#44183 で報告されたWindows環境での HTTP/2 接続シャットダウン時の OperationCanceledException を解決
  • GOAWAY フレームの確実な送受信とリソースクリーンアップの同期により、テストの信頼性が向上
  • リソース管理のベストプラクティス(using 宣言・try/finally ブロック)の適用も含まれます

#124384 [HTTP] Remove stale ActiveIssue overrides for #72586

  • 作成者: @ManickaP
  • 作成日時: 2026年02月13日 14:37:05(UTC)
  • マージ日時: 2026年02月16日 09:12:00(UTC)
  • ラベル: area-System.Net.Http

概要

Issue #72586(2022年10月に解決)に関連する古いActiveIssue属性をテストメソッドから削除しました。これにより、HTTP/1レスポンスストリームの応答キャンセル適合性テストが再度実行されるようになります。以前はTask.CompletedTaskを返していた3つのテストメソッドオーバーライドが不要になったため、ベースクラスのCancelPendingテストが実行可能になります。

変更内容

  • ResponseStreamConformanceTests.cs: 31行削除
    • Http1CloseResponseStreamConformanceTestsHttp1RawResponseStreamConformanceTestsからActiveIssue(72586)属性が付与された3つのテストメソッドオーバーライドを削除
    • ReadAsync_CancelPending*関連のテストメソッドが削除対象

パフォーマンスへの影響

影響なし。テストコードの削除であり、ランタイムコードの変更ではありません。ただし、削除によりConnectedStreamConformanceTestsの共有テストカバレッジが再度実行されるため、HTTP/1レスポンスストリームのキャンセル動作に関するテスト範囲が拡大します。

関連Issue

#72586(2022年10月に解決済み)

その他

このPRはメンテナンス的な変更です。解決済みのIssueに紐付けられたActiveIssue属性を削除することで、テストコードをクリーンアップし、不要な条件分岐を排除しています。HTTP/1レスポンスストリームのキャンセル機能が正常に動作していることが前提となっています。


#124373 JIT: Remove dataSection flexible array

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月13日 10:35:36(UTC)
  • マージ日時: 2026年02月16日 12:00:35(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT コンパイラの dataSection フレキシブル配列を削除し、より安全で保守性の高い実装に置き換えました。フレキシブル配列内にポインタと emitLocation インスタンスを格納する際のアラインメント問題を解決しています。

変更内容

  • emit.h: dataSection フレキシブル配列の定義を削除し、代替となるシンプルな表現に変更(26行追加、4行削除)
  • emit.cpp: フレキシブル配列の使用部分を置き換え、新しい実装パターンに更新(34行追加、33行削除)
  • codegencommon.cpp, codegenlinear.cpp, emitarm.cpp, emitxarch.cpp: dataSection 参照箇所を小規模に更新(各ファイル1行追加、1行削除)

パフォーマンスへの影響

作成者の説明から、フレキシブル配列はマイクロ最適化目的であったため、これを削除することでのパフォーマンス低下は最小限と考えられます。むしろ、アラインメント問題の解決による信頼性向上が重視されています。

関連Issue

#124350

その他

このPRは主にメモリアラインメントのフットガンを排除し、コード保守性を向上させることを目的としています。フレキシブル配列による最適化の必要性より、実装の正確性と安定性を優先した判断です。


#124308 [release/10.0] Fix lookup for current Thread in async signal handler

  • 作成者: @janvorli
  • 作成日時: 2026年02月12日 01:41:17(UTC)
  • マージ日時: 2026年02月16日 13:31:10(UTC)
  • ラベル: Servicing-approved area-VM-coreclr

概要

async signal handlerからThread Local Storage (TLS)にアクセスする際のクラッシュを修正するバックポート。最新のglibc版でのメモリ割り当て中の割り込み時にクラッシュする問題を解決するため、lock-freeでasync-safeなスレッドマップを実装し、signal handlerからの安全なスレッド検索を可能にしました。

// 従来: TLSアクセスでクラッシュの可能性
Thread* pThread = GetThread(); // signal handlerから呼び出すと危険

// 修正後: async-safe検索
Thread* pThread = GetThreadAsyncSafe(); // signal handlerでも安全

変更内容

  • asyncsafethreadmap.h/cpp: lock-free segmented hash tableによるasync-safe thread map実装
  • threads.h/cpp: GetThreadAsyncSafe()関数の追加と、スレッド生成時の非同期マップ管理
  • threadsuspend.cpp: CheckActivationSafePoint()をasync-safe lookup使用に更新、reader lockを回避
  • codeman.h/cpp: IsManagedCodeNoLock()追加(reader lock未取得時の使用)
  • minipal/thread.h: minipal_get_current_thread_id_no_cache()関数追加(TLSなしでスレッドID取得)
  • signal.cpp: signal handlerのrefactoring、常に元のハンドラを呼び出す
  • NativeAOT対応: threadstore.cpp/h、PalUnix.cpp、PalMinWin.cppの更新

パフォーマンスへの影響

  • 改善点: async-safe thread lookupはlock-freeなため、reader lockによる競合を削減し、signal handler内での遅延軽減
  • オーバーヘッド: スレッド生成/破棄時にlock-free map管理の追加処理(新規スレッドマップへの登録)
  • 実行頻度: 新規コードはsignal handlerで非常に頻繁に実行されるが、2ヶ月mainで検証済みで問題なし

関連Issue

#122513(main版の元の修正)

その他

  • 互換性: Unix(WASM除く)プラットフォームに限定、Windows互換性維持
  • リスク評価: Low - mainブランチで2ヶ月間検証済み、関連問題報告なし
  • 顧客影響: 報告済み - 特にUbuntu 25.04での最新glibc版で実際のクラッシュ例あり

#124298 [RyuJit/WASM] Implement internal registers

  • 作成者: @SingleAccretion
  • 作成日時: 2026年02月11日 21:29:59(UTC)
  • マージ日時: 2026年02月16日 17:08:38(UTC)
  • ラベル: arch-wasm area-CodeGen-coreclr community-contribution

概要

WebAssembly(WASM)バックエンド向けRyuJitに内部レジスタ機構を実装しました。これにより、DIV/MOD命令のゼロ除算チェックなど、一時的な値の保持が必要な操作をより効率的に処理できるようになります。内部レジスタは呼び出し元に見えないレジスタとして機能し、コード生成時に中間値を保存するために使用されます。

変更内容

  • codegencommon.cpp: 内部レジスタ管理の共通ロジック(149行追加)を実装
  • codegeninterface.h: 内部レジスタ関連のインターフェース定義(34行追加)を拡張
  • codegenwasm.cpp: WASM固有の内部レジスタ処理(44行追加、21行削除)を実装
  • regallocwasm.cpp/h: WASM向けレジスタアロケータに内部レジスタ対応(161行追加、26行追加)を追加
  • codegen.h, instrswasm.h, jithashtable.h: 各種定義とデータ構造の追加
  • stacklevelsetter.cpp: スタックレベル設定の微調整

パフォーマンスへの影響

改善点:

  • DIV/MOD操作のゼロ除算チェック時、内部レジスタを活用することでスタック操作の削減が期待できます
  • 中間値の管理がより効率的になり、メモリ変数の使用を減らせる可能性があります

具体的なベンチマーク数値は提供されていませんが、WASM環境でのレジスタ利用の最適化により、特に整数除算操作が頻繁なコードで性能向上が期待できます。

関連Issue

なし

その他

  • この変更はWASM固有の実装であり、他のプラットフォーム(x86/ARM等)への影響はありません
  • 内部レジスタは呼び出し規約に影響しないため、互換性への影響なし
  • RyuJit JIT実装の内部機構改善であり、ユーザーコードへの直接的な影響はありません

#124287 [release/10.0] Fix incorrect atomic loop optimization when body contains backtracking

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年02月11日 18:24:39(UTC)
  • マージ日時: 2026年02月16日 16:24:10(UTC)
  • ラベル: Servicing-approved area-System.Text.RegularExpressions

概要

.NET 10で導入されたアトミックループ最適化に関するバグを修正しました。ループ内にバックトラッキング構文(例:(?:...)?{n,m}など)がネストしている場合、正規表現が誤った結果を返していました。この修正により、そうしたケースでは最適化を無効にし、正確な結果を保証します。

// 例:以前は誤った結果を返していたパターン
// (?:a|b)+(?:c)?  など、ループ内にバックトラッキング構文がある場合

変更内容

  • RegexNode.cs: ループ内のバックトラッキング検出ロジックを追加(+56行)。アトミックループ最適化の適用条件をより厳密に判定
  • RegexTreeAnalyzer.cs: 最適化判定ロジックを簡素化(-6行の削減)
  • Regex.Match.Tests.cs: バックトラッキング構文を含む複数の新規テストケースを追加(+36行)

パフォーマンスへの影響

低リスク。特定のエッジケース(ループ内のバックトラッキング構文を含む正規表現)では最適化が無効化されるため、わずかに実行速度が低下する可能性があります。ただし、この最適化は.NET 10で新たに追加されたため、既存のコードへの回帰は限定的です。正確性と互換性が優先されています。

関連Issue

#124254(親PR、本体へのバックポート元)

その他

  • 重要度: .NET 10、P6またはP7の不具合
  • 顧客報告: あり(カスタマーからのレポートに基づく修正)
  • リスク評価: 低。最適化の無効化が追加対象であり、過度に無効化するリスクは限定的
  • ワークアラウンド: 修正までは正規表現パターンの変更で対応可能

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年02月10日 17:17:09(UTC)
  • マージ日時: 2026年02月16日 18:55:22(UTC)
  • ラベル: area-codeflow

概要

dotnet/dotnetリポジトリからのコードフロー更新PR。複数の依存パッケージが更新されており、主にRoslyn(コンパイラ)、NuGet関連ツール、ランタイムコンポーネント、ビルドツールが含まれます。2026年2月10日時点のビルド20260210.16から同期されました。

変更内容

主な更新内容:

  • Roslyn/Analyzer: Microsoft.CodeAnalysis系パッケージが5.4.0→5.5.0へ更新
  • NuGet Tools: NuGet.Frameworks、NuGet.Packaging、NuGet.ProjectModelが7.3.0→7.5.0へアップグレード
  • .NET Core Runtime: Microsoft.NETCore.App.Ref、System.Reflection.Metadataなどが11.0.0-preview.1→preview.2へ更新
  • ビルドツール: Microsoft.DotNet.Arcade.Sdk等のビルドインフラストラクチャパッケージを更新
  • JIT/LLVM Tools: 複数プラットフォーム向けのランタイムツール(linux-arm64、linux-x64、osx-arm64、osx-x64、win-x64など)を更新
  • WebAssembly: Node.Transportランタイムパッケージが複数プラットフォームで更新

変更ファイル:

  • eng/Version.Details.props/xml、global.json:依存パッケージバージョン定義
  • ビルド設定:publish-build-assets.yml、source-build.yml、post-build.yml
  • ネイティブビルド:build-rootfs.sh、install-dependencies.sh
  • プロジェクトファイル:複数の.csprojファイル

パフォーマンスへの影響

影響なし(コードフロー更新のため、本体コード変更なし。パッケージのアップデートにより将来的な最適化の恩恵を受ける可能性あり)

関連Issue

なし

その他

  • このPRはCodeflow PRで自動生成されたもの
  • 複数の関連ソースリポジトリ(arcade、aspnetcore、roslyn、efcore等)の変更を統合
  • darc VMRを使用して差分確認可能

#124136 [release/10.0] Source code updates from dotnet/dotnet

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年02月08日 01:39:46(UTC)
  • マージ日時: 2026年02月16日 18:56:53(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPRはVMR(Virtual Monorepo)の dotnet/dotnet リポジトリからの定期的なコードフロー更新です。release/10.0.1xx ブランチのコンパイラ、ビルドツール、テストフレームワーク、ランタイムなど複数の依存パッケージが更新されています。特にMicrosoft.CodeAnalysis関連とMicrosoft.DotNet.Arcade.Sdkなどのビルド基盤パッケージが2月10日~11日のビルドに更新されました。

変更内容

  • NuGet.config: フィード設定の軽微な更新(+1/-1行)
  • eng/Version.Details.props / Version.Details.xml: 依存パッケージバージョン情報の一括更新(37項目)
    • Microsoft.CodeAnalysis系: 5.0.0-2.26102.102 → 5.0.0-2.26110.124
    • Microsoft.DotNet.Arcade.Sdk: 10.0.0-beta.26102.102 → 10.0.0-beta.26110.124
    • NuGet.*: 7.0.2-rc.10302 → 7.0.2-rc.11124
    • WebAssembly Node Runtime: 10.0.0-alpha.1.26076.1 → 10.0.0-alpha.1.26104.2
  • eng/common/core-templates/job/source-build.yml: ソースビルド設定の更新
  • global.json: .NET SDK バージョン参照の更新

パフォーマンスへの影響

影響なし。このPRは依存パッケージの定期的なバージョン更新と設定ファイルの同期であり、ランタイム動作やコンパイルパフォーマンスへの直接的な影響情報は含まれていません。

関連Issue

なし

その他

  • 自動マージPR: dotnet-maestro[bot]による自動生成のコードフロー更新
  • リポジトリ同期: arcade、aspnetcore、efcore、runtime、sdk、sourcelink、windowsdesktop、winforms、wpfなど複数のリポジトリとの同期を含む
  • ブランチ対象: release/10.0ブランチへの更新であり、.NET 10.0.1xxの提供版に対応

#121698 Fix FileSystemWatcher macOS start performance

  • 作成者: @ezhevita
  • 作成日時: 2025年11月17日 07:40:20(UTC)
  • マージ日時: 2026年02月16日 16:35:05(UTC)
  • ラベル: area-System.IO community-contribution

概要

macOS上のFileSystemWatcher起動時のパフォーマンス問題(Issue #77793)を修正しました。不要なInterop.Sys.Sync()呼び出しを削除することで、ウォッチャーインスタンスあたり約45msの遅延を解消しています。FSEventStream APIは既にkFSEventStreamEventIdSinceNowで設定されており、新規イベントのみを受信するため、バッファフラッシュは不要でした。

変更内容

  • FileSystemWatcher.OSX.cs: 起動時の高コストSync()呼び出しを削除
  • Interop.Sync.cs: 不要になったP/Invoke定義を削除
  • System.IO.FileSystem.Watcher.csproj: Interop.Sync参照を削除
  • テストインフラ: ExpectEvents ヘルパーを強化し、イベント収集時にフィルタリング処理を実施(競合状態のバグを修正)
  • テストケース更新: FileSystemWatcher.File.Move.cs と FileSystemWatcher.Directory.Move.cs で新しいフィルタパラメータを使用

パフォーマンスへの影響

大幅な改善

  • FileSystemWatcher起動時のレイテンシ: 1インスタンスあたり約45ms削減
  • Interop.Sys.Sync()はOS全体のファイルバッファをフラッシュするため、複数ウォッチャーインスタンスでは累積的な改善が期待できます
  • メモリ使用量: 不要なP/Invoke定義削除により微減

関連Issue

  • Issue #77793 (FileSystemWatcher macOS起動パフォーマンス問題)

その他

  • テスト信頼性が向上:イベント収集時フィルタリングにより、競合状態に起因する誤カウントを防止
  • 内部実装の整理:使用されなくなったInterop定義を完全に削除し、保守性を向上

#121343 [release/9.0-staging] Update dependencies from dotnet/roslyn

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2025年11月04日 17:20:01(UTC)
  • マージ日時: 2026年02月16日 16:38:08(UTC)
  • ラベル: Servicing-approved linkable-framework area-codeflow

概要

dotnet/runtimeの release/9.0-staging ブランチを対象に、dotnet/roslyn からの依存関係を更新するPull Requestです。Roslyn 4.12.0 から 4.14.0、CodeAnalysis.Analyzers 3.11.0-beta1 から 3.12.0-beta1 へアップグレードされています。これに伴い、複数のテストファイルが整理・調整されています。

変更内容

  • eng/Version.Details.xml: Microsoft.CodeAnalysis、Microsoft.CodeAnalysis.CSharp、Microsoft.Net.Compilers.Toolset、Microsoft.CodeAnalysis.Analyzers のバージョン情報を更新
  • eng/Versions.props: Roslyn関連の依存バージョンを更新
  • eng/SourceBuildPrebuiltBaseline.xml: ソースビルド対象の新しいプリビルト パッケージ情報を追加
  • LibraryImportGenerator.UnitTests/*.cs (4ファイル): カスタムマーシャラー属性フィクサーテストの不要なテストケースを削除
  • UpgradeToGeneratedRegexAnalyzerTests.cs: 生成済みRegexアナライザーテストを調整
  • illink関連の2ファイル: ILLink RoslynAnalyzer テスト生成プロジェクトとデータフロー分析テストを更新

パフォーマンスへの影響

影響なし(依存関係更新のみ)

関連Issue

なし

その他

このPull Requestは、dotnet-maestro[bot]による自動更新です。複数のレビュワーによる承認プロセスを経ています。変更内容から、Roslynの新バージョンで一部テストケースが不要になったか、テスト検証方法が改善されたことが推測されます。


#120899 [System.DirectoryServices] Fixed possible resource leak

  • 作成者: @sancheolz
  • 作成日時: 2025年10月20日 12:06:16(UTC)
  • マージ日時: 2026年02月16日 15:30:06(UTC)
  • ラベル: area-System.DirectoryServices community-contribution

概要

System.DirectoryServices ライブラリにおいて、SafeLsaPolicyHandle オブジェクトの適切なリソース解放を実装しました。SafeLsaPolicyHandle は LSA ポリシーハンドルをラップする SafeHandle 型であり、ネイティブリソースを確実に解放するために明示的な破棄が必要です。静的分析ツール SVACE により検出されました。

変更内容

  • TrustHelper.cs: SafeLsaPolicyHandle の使用パターンを改善
    • 7つのメソッドで using var パターンを導入し、自動的なリソース破棄を実装
    • GetTrustedDomainInfo メソッドではハンドル再割り当てが発生するため、明示的な Dispose 呼び出しを追加

具体例:

// 変更前(リソースリークの可能性)
SafeLsaPolicyHandle policyHandle = new SafeLsaPolicyHandle(...);
// 処理...
// policyHandle が破棄されない

// 変更後(自動破棄)
using var policyHandle = new SafeLsaPolicyHandle(...);
// 処理...
// スコープ終了時に自動破棄

パフォーマンスへの影響

直接的な性能改善はありませんが、ネイティブリソーク(LSA ポリシーハンドル)の確実な解放により、メモリリークを防止し、長時間実行アプリケーションの安定性が向上します。

関連Issue

なし

その他

  • Linux Verification Center の SVACE 静的分析により発見
  • SafeHandle 派生クラスの適切な破棄パターンは .NET 開発者向けの重要なベストプラクティスです
  • Active Directory 関連機能を使用するアプリケーションで効果が期待できます

#119644 Fixed excessive capacity allocation in ValueListBuilder<T>

  • 作成者: @kzrnm
  • 作成日時: 2025年09月12日 14:39:27(UTC)
  • マージ日時: 2026年02月16日 12:48:53(UTC)
  • ラベル: area-System.Runtime community-contribution

概要

ValueListBuilder<T>.Growメソッドの過度なキャパシティ割り当てバグを修正しました。Growメソッドに渡す引数が誤っていたため、必要以上のメモリが確保されていました。この修正により、ValueStringBuilderと同じ割り当てロジックに統一されます。

// 修正前: AppendSpan(100)時にキャパシティが256になる
var vlb = new ValueListBuilder<char>();
vlb.AppendSpan(17);  // キャパシティ: 32
vlb.AppendSpan(100); // キャパシティ: 256(過度な割り当て)

// 修正後: 正しく128になる
vlb.AppendSpan(17);  // キャパシティ: 32
vlb.AppendSpan(100); // キャパシティ: 128(期待値)

変更内容

  • ValueListBuilder.cs: AppendMultiCharAppendSpanWithGrowGrow呼び出しで、_span.Length - _pos + additionalLengthではなくadditionalLengthを渡すように修正。オーバーフロー判定を簡素化し、Disposeメソッドのパターンを改善
  • ValueListBuilder.Pop.cs: CoreLibから共通ディレクトリに移動
  • ValueListBuilderTests.cs: 新規追加。キャパシティ割り当てを検証する包括的なテストスイート
  • ValueStringBuilderTests.cs: キャパシティテストを追加し、両者の一貫性を確保
  • プロジェクト参照更新: System.Private.CoreLibからCommonへの参照移動に対応して、複数のプロジェクトファイル(System.Text.RegularExpressions、System.Text.Json、System.Runtime.Numericsなど)を更新

パフォーマンスへの影響

改善点: メモリ使用量が削減されます。大量の要素を追加する際、過度に確保されていたメモリが適切なサイズになることで、ガベージコレクション圧力が軽減されます。特にValueListBuilderを多用するJSON解析や正規表現処理などで顕著な改善が期待できます。

関連Issue

Issue番号の記載がないため確認できません。

その他

  • ValueListBuilderファイルがSystem.Private.CoreLibからCommonに移動したため、テスト可能性が向上しました。これは内部実装の改善で、公開APIへの影響はありません。
  • 互換性への影響なし(破壊的変更ではない)。

#118932 Improve ImmutableArrayExtensions.SequenceEqual

  • 作成者: @prozolic
  • 作成日時: 2025年08月20日 16:25:05(UTC)
  • マージ日時: 2026年02月16日 03:36:41(UTC)
  • ラベル: area-System.Collections tenet-performance community-contribution

概要

ImmutableArrayExtensions.SequenceEqualメソッドのパフォーマンスを大幅に改善するPRです。ICollection<T>を実装するコレクション向けに高速パスを追加し、Enumerable.SequenceEqualに委譲することで、配列・リストで約90%の高速化を実現しています。純粋なIEnumerable<T>型に対しては既存実装を保持し、互換性を維持しています。

変更内容

  • ImmutableArrayExtensions.cs: SequenceEqualメソッドにICollection<T>検出ロジックを追加。高速パス(ICollection<T>向け)と従来の実装へのフォールバックの二層構造を実装
  • ImmutableArrayExtensionsTest.cs: ToEnumerableヘルパーメソッドを追加し、高速パスとフォールバック両経路の包括的なテストカバレッジを実装

パフォーマンスへの影響

大幅な改善

  • Array: 10% (68.885ns → 6.856ns、約90%削減)
  • List: 9% (85.014ns → 7.676ns、約91%削減)
  • IList: 46% (125.897ns → 57.836ns、約54%削減、メモリ割り当て排除)

ICollection・IEnumerable型では統計的に有意な差異なし。メモリ割り当ては削減されています。

関連Issue

#118932

その他

実装はレビュアーからのフィードバック(@neon-sunset、@xtqqczze)に基づいて最適化されており、複雑性とパフォーマンスのバランスを実現しています。IEnumerable<T>向けの既存実装を保持した理由は、既存実装がより優れたパフォーマンスを提供し、2番目の列挙子割り当てを回避できるためです。


目次