Pull Request on 2026年01月21日

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

注意点

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

目次

  1. #123450 Change pool for evaluate-paths
  2. #123441 Remove unused THREADGetThreadProcessId function.
  3. #123430 Rework and enable Wasm.Build.Tests.Blazor.AssetCachingTests
  4. [#123423 browser][CoreCLR] fix pinvoke
  5. #123388 Rework and enable Wasm.Build.Tests.Blazor.AssetCachingTests
  6. #123387 [release/10.0] Source code updates from dotnet/dotnet
  7. #123382 Work-around memset namespace issue on SunOS
  8. #123366 [browser] JS interop fix marshalling of completed task of long
  9. #123343 JIT: Make async insertion of "rethrow BB" deterministic to fix debug info
  10. [#123330 browser][ST] test trimming of System.Collections.Concurrent
  11. #123327 [browser] LoopbackServer - make GenericLoopbackServer.CloseWebSocket async
  12. #123304 [browser] Use Runtime=NET for build tasks in WebAssembly SDK
  13. #123203 [main] Update dependencies from dotnet/icu, dotnet/runtime-assets
  14. #123192 Fix truncated exe file name in .NET core mini dump file name
  15. #123191 Add interpreter libraries tests to CI
  16. #123045 Add pipeline to validate source-build stage1+2 builds from within runtime
  17. #122371 Update OpenSUSE Helix testing from 15.6 to 16.0
  18. #121429 [release/9.0] Update dependencies from dotnet/arcade
  19. #120306 Add IReadOnlySet support to System.Text.Json
  20. #118415 [EventPipe] Remove thread lock and cleanup ThreadSessionState lifecycle

#123450 Change pool for evaluate-paths

  • 作成者: @hoyosjs
  • 作成日時: 2026年01月21日 22:45:46(UTC)
  • マージ日時: 2026年01月21日 23:16:50(UTC)
  • ラベル: needs-area-label

概要

Azure DevOps パイプラインの evaluate-paths ジョブで使用されるランナーを Ubuntu から macOS に変更しました。ビルドパイプラインの実行環境を macOS ベースに統一することで、プラットフォーム固有の動作検証を強化します。

変更内容

  • eng/pipelines/common/evaluate-paths-job.yml
    • evaluate_paths ジョブの VM イメージ指定を ubuntu-latest から macos-latest に変更
    • パイプライン設定のみの変更で、ランタイムコードへの影響はなし

パフォーマンスへの影響

macOS ランナーの利用による以下の点を考慮：

  • macOS ランナーの起動時間と実行環境のセットアップに若干の時間差が発生する可能性
  • 具体的なベンチマーク値は提供されていないため、実際のパフォーマンス差異は運用後に検証が必要
  • CI/CD パイプラインのスループットへの影響は限定的と予想

関連Issue

なし

その他

  • パイプライン設定のみの変更のため、ソースコードの機能に影響なし
  • macOS 環境での パス評価ロジックの検証強化が目的と考えられる
  • レビュアーに jkoritzinsky、agocke が含まれており、パイプライン変更の適切な承認プロセスが取られている

#123441 Remove unused THREADGetThreadProcessId function.

  • 作成者: @adityamandaleeka
  • 作成日時: 2026年01月21日 16:59:56(UTC)
  • マージ日時: 2026年01月21日 21:25:44(UTC)
  • ラベル: area-System.Threading

概要

CoreCLR PALのスレッド実装から、未使用のTHREADGetThreadProcessId関数を削除するコミットです。この関数はロジカルバグ（エラーハンドリング条件が反転している）を含んでいたため、削除することで技術負債を軽減します。

変更内容

ファイル 変更内容
src/coreclr/pal/src/thread/thread.cpp THREADGetThreadProcessId関数を削除（53行削除、ドキュメントコメント含む）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

本変更は純粋なコードクリーンアップです。削除される関数はすでに呼び出し元がなく、かつ含まれていたロジカルバグ（成功時にエラーログを記録し、エラー時にプロセスIDを返そうとするという反転した条件）の修正と同時にコードベースから完全に排除されます。このアプローチにより、バグ修正と不要なコード削除を1つのコミットで効率的に処理しています。

#123430 Rework and enable Wasm.Build.Tests.Blazor.AssetCachingTests

  • 作成者: @Copilot
  • 作成日時: 2026年01月21日 11:59:56(UTC)
  • マージ日時: 2026年01月21日 13:18:26(UTC)
  • ラベル: 指定なし

概要

AssetCachingTestsの不安定性を解決するため、サーバーログのstdout解析からAPI ベースのアプローチに変更しました。BlazorWebWasmテストサーバーにリクエストログミドルウェアと/request-logsAPIエンドポイントを追加し、BlazorWebWasmLogClientを通じてHTTP経由でログを取得するように改善しました。また、C# 13のnew Lock()とコレクション式[]の新しい構文も導入しています。

変更内容

  • BlazorWebWasmLogClient.cs (+1/-1): リクエストログをHTTP経由で取得するクライアント実装
  • Program.cs (+1/-1): BlazorWebWasmテストサーバーのミドルウェアとエンドポイント設定
  • BuildWasmAppsJobsList.txt: AssetCachingTestsの再有効化

パフォーマンスへの影響

stdout解析からAPI ベースの取得に変更することで、ログ収集の信頼性が向上し、テストの不安定性を排除します。スレッドセーフなログ収集のためLock()を使用しており、メモリ効率も改善されます。

関連Issue

#123430

その他

  • スレッド安全性: C# 13のLock()を採用し、object()の使用を廃止
  • 構文改善: Array.Empty<T>()をコレクション式[]に統一
  • テスト改善: stdout解析の非決定性を排除し、テストの安定性を向上

#123423 [browser][CoreCLR] fix pinvoke

  • 作成者: @pavelsavara
  • 作成日時: 2026年01月21日 09:20:37(UTC)
  • マージ日時: 2026年01月21日 13:08:57(UTC)
  • ラベル: arch-wasm area-Interop-coreclr os-browser

概要

ブラウザ環境でのWebAssembly実行時におけるPInvoke呼び出しの問題を修正するPRです。WasmAppBuilderのPInvokeモジュールリストに、ブラウザ固有の2つのネイティブモジュール（libSystem.Native.BrowserとlibSystem.Runtime.InteropServices.JavaScript.Native）を追加することで、PInvoke機能の適切な動作を確保しています。

変更内容

  • WasmAppBuilder.csproj: WasmPInvokeModuleリストに2つのブラウザ固有ネイティブモジュールを追加（+2行）
  • pinvoke_override.cpp: ブラウザ環境向けのPInvoke実装を追加（+12行）
  • callhelpers-pinvoke.cpp: PInvoke呼び出しヘルパー機能を拡張（+17行）
  • callhelpers-reverse.cpp: リバースPInvoke（マネージドコードへのネイティブコールバック）の実装を改善（+16行）

パフォーマンスへの影響

影響なし。本修正はPInvoke機能の正確な動作を確保するものであり、パフォーマンス特性には変化がありません。

関連Issue

#123421

その他

  • ブラウザ/WebAssembly環境でのマネージドコードからネイティブコード呼び出しに関する修正
  • CoreCLRのWasm実行環境における相互運用機能の補強

#123388 Rework and enable Wasm.Build.Tests.Blazor.AssetCachingTests

  • 作成者: @oroztocil
  • 作成日時: 2026年01月20日 17:18:54(UTC)
  • マージ日時: 2026年01月21日 16:59:33(UTC)
  • ラベル: arch-wasm test-enhancement area-Infrastructure-mono os-browser

概要

WebAssembly Blazor アセットキャッシング テストの信頼性を改善するPRです。従来のサーバーログの標準出力解析に依存していたため不安定だったAssetCachingTestsを、HTTP APIエンドポイントベースのログ取得メカニズムに置き換えました。テストサーバーに/request-logsエンドポイントを追加し、クライアント側から専用のHTTPクライアント(BlazorWebWasmLogClient)でログを取得する方式に統一しています。

変更内容

  • BlazorWebWasm/Program.cs: リクエストログキャプチャミドルウェアと、ログ取得・クリア機能を持つAPIエンドポイント（/request-logs）を追加
  • BlazorWebWasmLogClient.cs: テストコードからログAPI呼び出しを行うためのHTTPクライアント新規作成
  • BlazorWebWasmRequestLog.cs: サーバーとテスト側で共有するリクエスト詳細キャプチャレコード型を定義
  • Counter.razor: 初回レンダリング時のみログを記録するよう最適化
  • AssetCachingTests.cs: stdout解析廃止、新APIベースのログ取得方式に リファクタリング（ActiveIssue属性を削除）
  • BlazorWebWasm.csproj / BlazorWebWasm.Client.csproj: ターゲットフレームワークを net10.0 → net11.0 に更新
  • BuildWasmAppsJobsList.txt: AssetCachingTests をテスト実行対象に再追加

パフォーマンスへの影響

影響なし。本変更はテスト信頼性の改善が主目的で、ランタイムアセットキャッシング動作自体への変更はありません。

関連Issue

なし

その他

このPRは、アセットフィンガープリント有効時のブラウザキャッシュ動作検証（初回ロード後は常にキャッシュから取得すること）をより堅牢に確認するための改善です。stdout ベースのログ解析がflaky テストの原因だったため、構造化APIエンドポイント経由の取得に統一することで、テスト実行の安定性が向上するものと考えられます。

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月20日 16:59:27(UTC)
  • マージ日時: 2026年01月21日 16:09:48(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPRは、dotnet/dotnetリポジトリからdotnet/runtimeへのコードフロー更新です。Microsoft.CodeAnalysisやMicrosoft.DotNetツールチェーン、NuGetライブラリなど複数の依存パッケージをアップデートしています。2026年1月20日付けのビルド20260120.4から、コンパイラ、ビルドタスク、テストフレームワークの最新版を取り込みます。

変更内容

  • eng/Version.Details.props - 29行の更新（パッケージメタデータ）
  • eng/Version.Details.xml - 69行の更新（依存パッケージ版情報）
  • global.json - 5行の更新（SDK版情報）
  • NuGet.config - 1行の更新（NuGetソース設定）

主要な依存パッケージ更新：

  • Microsoft.CodeAnalysis系: 5.0.0-2.26062.108 → 5.0.0-2.26070.104
  • Microsoft.DotNet Arcade/Build.Tasks系: 10.0.0-beta.26062.108 → 10.0.0-beta.26070.104
  • NuGet.Frameworks/Packaging/ProjectModel: 7.0.2-rc.6308 → 7.0.2-rc.7104

パフォーマンスへの影響

影響なし（自動コードフロー更新による依存パッケージのアップデート）

関連Issue

なし

その他

このPRは自動化されたコードフロー更新（Maestro bot）です。aspnetcore、efcore、msbuild、roslyn、sdk、winforms等の複数リポジトリからの関連変更を含みます。release/10.0ブランチへの統合です。

#123382 Work-around memset namespace issue on SunOS

  • 作成者: @gwr
  • 作成日時: 2026年01月20日 15:00:23(UTC)
  • マージ日時: 2026年01月21日 10:32:31(UTC)
  • ラベル: area-VM-coreclr community-contribution

概要

SunOS（illumos/Solaris）プラットフォーム上で発生するmemsetのnamespace問題に対するワークアラウンドを実装しました。std::memsetを明示的に使用することで、プラットフォーム固有の問題を回避しつつ、他のプラットフォームでの既存動作を維持しています。

#ifdef TARGET_SUNOS
    std::memset(ptr, 0, size);  // SunOS上で明示的なnamespace指定
#else
    memset(ptr, 0, size);        // 他のプラットフォーム
#endif

変更内容

  • src/coreclr/vm/qcallentrypoints.cpp
    • TARGET_SUNOSの条件付きコンパイル処理を追加
    • SunOS環境でのmemsetの呼び出しをstd::memsetに明示的に変更
    • 変更行数：+5/-0

パフォーマンスへの影響

影響なし。これはコンパイラレベルのnamespace解決の問題であり、実行時パフォーマンスへの変更はありません。

関連Issue

  • #123368（本PR）
  • #17832（illumos.org）

その他

  • SunOS（illumos/Solaris）固有の問題に対する限定的な修正
  • 他のプラットフォームへの影響なし
  • プラットフォーム特有のコンパイラ動作差異に対応

#123366 [browser] JS interop fix marshalling of completed task of long

  • 作成者: @ArcadeMode
  • 作成日時: 2026年01月20日 00:25:34(UTC)
  • マージ日時: 2026年01月21日 09:26:24(UTC)
  • ラベル: arch-wasm area-System.Runtime.InteropServices.JavaScript community-contribution os-browser

概要

Browser向けJS相互運用機能において、完了済みTask<long>のマーシャリング時にバグが発生していました。完了済みタスクの値を直接マーシャリングする最適化パスで、型固有のマーシャラーではなく汎用のToJS(object)メソッドが呼ばれており、long型はnumberとbigintの2通りのマーシャリング方法があるためNotSupportedExceptionが発生していました。本修正により、完了済みタスクでも型固有のマーシャラーデリゲートを使用するよう統一されます。

変更内容

  • JSMarshalerArgument.Task.cs: 完了済みタスクの結果マーシャリング時に、汎用ToJS(object)から型固有のマーシャラーデリゲート(marshaler(ref this, result))を使用するように修正（1行変更）
  • JSExportTest.cs: Task<long>マーシャリングのテストケース2つを追加
    • JsExportTaskOfLong: 未完了のタスク（相互運用境界を超えた後に完了）
    • JsExportCompletedTaskOfLong: 完了済みタスク（修正前はこのテストが失敗）
  • JavaScriptTestHelper.cs: テスト用のJSImport/JSExportメソッドを追加（invoke1_TaskOfLong、AwaitTaskOfInt64）

パフォーマンスへの影響

影響なし

本修正は実行パスの変更ですが、既存の完了済みタスク最適化パスは維持され、単にマーシャラー選択ロジックの正確性が向上するのみです。

関連Issue

なし

その他

互換性・技術的なポイント

  • この修正は破壊的変更ではなく、バグ修正です
  • 修正前：完了済みTask<long>はToJSNotSupported, Int64エラーで実行時に失敗
  • 修正後：ユーザー設定に応じてnumberまたはbigintとして正しくマーシャリング
  • 修正はコードジェネレーションが提供するマーシャラーデリゲートを信頼し活用する設計になっています

#123343 JIT: Make async insertion of "rethrow BB" deterministic to fix debug info

  • 作成者: @jakobbotsch
  • 作成日時: 2026年01月19日 11:51:38(UTC)
  • マージ日時: 2026年01月21日 09:18:05(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITのasync変換処理において、例外の再スロー（rethrow）用基本ブロック（BB）の挿入位置が非決定的だったため、デバッグ情報が破損する問題を修正しました。fgNewBBinRegionからfgNewBBafterへ変更することで、rethrow BBを常にAsync呼び出しの直後に挿入するようにしました。

// 修正前: 挿入位置が非決定的
fgNewBBinRegion(...)

// 修正後: async呼び出し後に確実に挿入
fgNewBBafter(...)

変更内容

  • src/coreclr/jit/async.cpp: async resumptionにおけるrethrow BB挿入ロジックの改善
    • fgNewBBinRegionからfgNewBBafterへAPI変更（決定的な挿入位置の保証）
    • BBF_INTERNALフラグ削除条件の簡略化（挿入位置が確定したため）
    • コメント更新（決定的挿入動作を反映）

パフォーマンスへの影響

影響なし。これはコード生成の正確性を改善する修正であり、パフォーマンスへの直接的な影響はありません。

関連Issue

#123316（デバッグ情報が破損するissue）

その他

この修正はデバッグ情報の正確性に関わる重要な修正です。非決定的な基本ブロック挿入によるデバッグ情報破損は、再現性のないバグやデバッグの困難さにつながるため、決定的な動作への改善は品質向上に寄与します。

#123330 [browser][ST] test trimming of System.Collections.Concurrent

  • 作成者: @pavelsavara
  • 作成日時: 2026年01月18日 17:26:14(UTC)
  • マージ日時: 2026年01月21日 13:03:29(UTC)
  • ラベル: arch-wasm area-System.Collections linkable-framework size-reduction os-browser

概要

シングルスレッド環境のBrowser WASM向けランタイムにおいて、System.Collections.Concurrentアセンブリ全体がトリミング（削除）されていることを検証するテストを追加しました。CoreLibが並行コレクション型に依存しないようにすることで、ダウンロードサイズを削減します。

変更内容

  • BrowserDoesNotIncludeConcurrentTypes.cs（新規作成、64行）

    • Browser WASM環境でシングルスレッド実行時に、System.Collections.Concurrentの型がトリミングされていることを検証するテストケース

  • System.Runtime.TrimmingTests.proj（3行追加）

    • 新しいトリミングテストをプロジェクトに条件付きで包含（シングルスレッドBrowser対象）

パフォーマンスへの影響

改善点：

  • Browser WASM向けビルドでダウンロードサイズを削減
  • 不要な並行コレクション実装がバイナリから除外される

懸念点： 影響なし（このPRはテストのみの追加であり、パフォーマンスへの直接的な影響はありません）

関連Issue

なし

その他

  • このテストは既存の実装ポリシー（CoreLibでシングルスレッドBrowser環境ではConcurrentQueue等を使用しない）の検証を目的としています
  • トリミングが期待通りに動作していることを継続的に確認するための回帰テストとして機能します
  • 対象は単一スレッド（ST）のBrowser WASM環境に限定されます

#123327 [browser] LoopbackServer - make GenericLoopbackServer.CloseWebSocket async

  • 作成者: @pavelsavara
  • 作成日時: 2026年01月18日 17:03:12(UTC)
  • マージ日時: 2026年01月21日 09:35:28(UTC)
  • ラベル: area-System.Net.Http os-browser

概要

ブラウザプラットフォームで Task.WaitAll の呼び出しを回避するため、ソケットクローズ操作を同期メソッドから非同期メソッドに変換しました。CloseWebSocket() を CloseWebSocketAsync() にリネームし、CloseAsync()、ShutdownAsync()、ShutdownSendAsync() を非同期メソッドに改善。テストコード全体で呼び出し箇所を修正しています。

// 変更前
Task.WaitAll(_socket.CloseWebSocket()); // ブラウザで PlatformNotSupportedException

// 変更後
await _socket.CloseWebSocketAsync();

変更内容

  • GenericLoopbackServer.cs: CloseWebSocket() → CloseWebSocketAsync() に変換、Close() と Shutdown() を非同期化、ブロッキング Task.WaitAll 呼び出しを削除
  • Http2LoopbackConnection.cs: ShutdownSend() → ShutdownSendAsync() に変換、null チェック追加
  • LoopbackServer.cs: CloseAsync()、ShutdownAsync() 呼び出し箇所を await 対応
  • テストファイル群（12ファイル）: ソケットの閉鎖・シャットダウン呼び出しを非同期版に更新

パフォーマンスへの影響

影響なし。変更はソケット操作の非同期化によるブロッキング回避が目的で、メモリ使用量や実行速度に直接的な改善・悪化はありません。ただしブラウザプラットフォームでの PlatformNotSupportedException を回避できるため、実行安定性が向上します。

関連Issue

明記されていません。

その他

  • 破壊的変更: パブリック API の CloseWebSocket() メソッド名が変更されているため、既存コードの更新が必要になる可能性があります（テストコード範囲内）
  • ブラウザプラットフォーム特有の制限対応: WebAssembly 環境では同期的なタスク待機がサポートされないため、この修正は WASM 環境でのテスト実行を可能にします

#123304 [browser] Use Runtime=NET for build tasks in WebAssembly SDK

  • 作成者: @Copilot
  • 作成日時: 2026年01月17日 10:35:27(UTC)
  • マージ日時: 2026年01月21日 16:52:16(UTC)
  • ラベル: arch-wasm area-Build-mono os-browser

概要

WebAssembly SDK のビルドタスクを MSBuild の Runtime="NET" 属性に対応させることで、レガシーなマルチターゲット対応を削除し、NuGet パッケージレイアウトを簡素化しました。Microsoft.NET.Sdk.WebAssembly.Pack.Tasks を単一ターゲット $(NetCoreAppToolCurrent) に変更し、タスク DLL を tools/ ディレクトリに直接配置するようになります。

変更内容

  • Microsoft.NET.Sdk.WebAssembly.Pack.Tasks.csproj: net472 マルチターゲット廃止、単一ターゲット化、タスク DLL/PDB を tools/ に直接出力
  • Microsoft.NET.Sdk.WebAssembly.Browser.targets: _WebAssemblySdkTasksTFM プロパティと TFM 選択ロジック削除、アセンブリパス更新、全 UsingTask に Runtime="NET" 属性追加（GenerateWasmBootJson、ComputeWasmBuildAssets、ComputeWasmPublishAssets、ConvertDllsToWebCil）
  • WasmApp.InTree.props: _WebAssemblySdkToolsDirectory パスに $(NetCoreAppToolCurrent) を含める
  • trimmingTests.targets: WasmSdkPackTasksPath パスに $(NetCoreAppToolCurrent) を含める

NuGet パッケージレイアウトの変更:

// 変更前
tools/net11.0/Microsoft.NET.Sdk.WebAssembly.Pack.Tasks.dll
tools/net472/Microsoft.NET.Sdk.WebAssembly.Pack.Tasks.dll

// 変更後
tools/Microsoft.NET.Sdk.WebAssembly.Pack.Tasks.dll

パフォーマンスへの影響

影響なし。本変更はビルドシステムの構成改善であり、実行時パフォーマンスに直結する変更ではありません。ただしタスク実行の信頼性が向上します。

関連Issue

#123155

その他

重要な互換性への影響: 本変更は UsingTask runtime 属性対応が不足している古い MSBuild（2024年以前のバージョン）とは互換性がありません。.NET SDK に組み込まれた MSBuild のみがサポート対象となります。Runtime="NET" 属性により、MSBuild ホストの TFM に関わらず、.NET Core 上でタスクが実行されることが保証されます。

#123203 [main] Update dependencies from dotnet/icu, dotnet/runtime-assets

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

概要

dotnet/runtimeの依存パッケージを自動更新するPull Requestです。dotnet/icuからICU Transport関連パッケージ、dotnet/runtime-assetsから複数のテストデータとランタイムアセットパッケージを更新しています。これらは定期的な依存関係の自動同期により、最新の国際化サポートとテストインフラストラクチャを保つためのものです。

変更内容

  • eng/Version.Details.props - 依存パッケージのバージョン情報を更新（17行追加/削除）
  • eng/Version.Details.xml - 依存パッケージの詳細情報を更新（34行追加/削除）

更新パッケージ：

  • Microsoft.NETCore.Runtime.ICU.Transport: 11.0.0-alpha.1.25631.1 → 11.0.0-alpha.1.26063.1
  • テストデータ関連: 16個のパッケージを11.0.0-beta.26059.1 → 11.0.0-beta.26064.1に更新
    • CIL Strip Sources、Unicode Data、TimeZone Data、各種テストデータなど

パフォーマンスへの影響

影響なし

国際化サポート（ICU）の更新により、グローバルアプリケーションの文字列処理やロケール対応の最新機能が利用可能になる可能性がありますが、パフォーマンス上の直接的な影響はありません。

関連Issue

なし

その他

  • このPRはdotnet-maestro[bot]による自動生成です。Maestroは.NET リポジトリの依存パッケージ管理を自動化するツールです
  • 更新対象がすべてアルファ/ベータ版であり、main ブランチ向けの開発段階の更新です
  • 変更内容が依存パッケージの構成情報のみであるため、コンパイルやテスト実行への直接的な影響は最小限です

#123192 Fix truncated exe file name in .NET core mini dump file name

  • 作成者: @barosiak
  • 作成日時: 2026年01月14日 19:52:00(UTC)
  • マージ日時: 2026年01月21日 21:20:24(UTC)
  • ラベル: bug area-Diagnostics-coreclr

概要

Linux上でmini dumpファイルを生成する際、DOTNET_DbgMiniDumpNameに%e.dmpを指定した場合、実行可能ファイル名が15文字に切り詰められていた問題を修正しました。

修正内容は、まず/proc/<pid>/exeシンボリックリンクから完全なパスを読み込み、失敗時は従来の/proc/<pid>/statusにフォールバックするという優先順位制御です。これにより、長いファイル名を正確に保持できます。

変更内容

  • src/coreclr/debug/createdump/crashinfounix.cpp
    • /proc/<pid>/exeから実行可能ファイルのフルパスを読み込む処理を追加（読み込み長制限なし）
    • readlinkで取得したパスからベースネームを抽出する処理を実装
    • 読み込み失敗時に/proc/<pid>/statusへの従来の方法にフォールバック
    • 後方互換性を維持しながら拡張

パフォーマンスへの影響

影響なし。追加の処理は条件分岐によるreadlinkシステムコール1回のみで、既存パスがフォールバックとして機能するため、例外的なシナリオでのオーバーヘッドは無視できるレベルです。

関連Issue

#83419

その他

  • ローカル環境でテスト済み（diagnostics repositoryにテストが追加予定）
  • Linux環境専用の修正
  • 破壊的変更なし

#123191 Add interpreter libraries tests to CI

  • 作成者: @janvorli
  • 作成日時: 2026年01月14日 19:46:29(UTC)
  • マージ日時: 2026年01月21日 08:35:35(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

CoreCLR インタープリタが有効な状態でライブラリテストを実行するための新しいCI パイプラインを追加します。このパイプラインは日次スケジュールで実行され、Linux、Windows、macOS の x64 および ARM64 アーキテクチャ全体でテスト可能にします。インタープリタのパフォーマンスオーバーヘッドに対応するため、タイムアウトは300分に設定されています。

変更内容

  • eng/pipelines/coreclr/libraries-interpreter.yml: 新規ファイル（+42行）
    • インタープリタ有効時のライブラリテスト用CI パイプライン定義
    • 日次スケジュール実行の設定
    • 複数プラットフォーム対応（Linux、Windows、macOS × x64/ARM64）
    • Helix テストインフラストラクチャとの統合

パフォーマンスへの影響

インタープリタ実行モードでのライブラリテスト実行により、通常のJIT コンパイル実行に比べて実行時間が大幅に増加することが想定されます。この対応として、CI タイムアウトを300分（通常の複数倍）に設定しています。これによりインタープリタ実装の正確性検証は可能になる一方、CI リソースの増加と実行時間の延伸が発生します。

関連Issue

なし

その他

  • Work-in-progress (WIP) 状態のPR のため、実装がまだ進行中の可能性があります
  • Helix 分散テストインフラを活用することで、複数プラットフォームでの効率的なテスト実行を実現しています

#123045 Add pipeline to validate source-build stage1+2 builds from within runtime

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年01月09日 21:08:45(UTC)
  • マージ日時: 2026年01月21日 22:15:43(UTC)
  • ラベル: test-enhancement source-build area-Infrastructure

概要

runtime リポジトリ内から VMR（Virtual Monolithic Repository）のソースビルド stage1/stage2 を検証する専用パイプラインを追加します。これにより、予期された失敗を含むソースビルドシナリオを非ブロッキングで検証できるようになります。既存の source-build 関連ジョブは廃止されます。

変更内容

ファイル 変更内容
eng/pipelines/vmr-build-pr.yml 新規追加：VMR テンプレート経由で stage1/stage2 ビルドを検証するパイプライン（ドキュメント、Markdown、Mono のパス除外対応）
eng/pipelines/runtime.yml SourceBuild ステージを削除（CentOS.9 および NonexistentRID 検証ジョブを廃止）
eng/pipelines/global-build.yml ポータブル Linux x64 ソースビルドジョブを削除

パフォーマンスへの影響

影響なし。本変更は CI/CD パイプラインの構成変更であり、ランタイムパフォーマンスには直接的な影響を与えません。

関連Issue

#122998 を修正

その他

  • 新規パイプラインは非ブロッキング設計のため、期待される失敗が通常のビルドをブロックしません
  • レガシー source-build ジョブの機能は VMR 検証に統合・置換されています
  • Build Analysis への統合は現段階では見送られています

#122371 Update OpenSUSE Helix testing from 15.6 to 16.0

  • 作成者: @Copilot
  • 作成日時: 2025年12月10日 00:28:36(UTC)
  • マージ日時: 2026年01月21日 05:42:48(UTC)
  • ラベル: area-Infrastructure

概要

OpenSUSE Helix テスト プラットフォームのバージョンを 15.6 から 16.0 に更新するインフラストラクチャのみの変更です。CI パイプライン設定ファイルにおいて、テスト実行環境で使用される OpenSUSE コンテナ イメージとキュー定義を更新します。

変更内容

  • eng/pipelines/helix-platforms.yml: helix_linux_x64_opensuse_latest 変数を更新し、opensuse-16.0-helix-amd64 コンテナ イメージを参照するよう変更
  • eng/pipelines/libraries/helix-queues-setup.yml: CoreCLR 追加プラットフォーム キュー定義を更新し、OpenSUSE 16.0 用の openSUSE.16.0.Amd64.Open キュー名に変更
  • src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs: プラットフォーム検出ロジックに OpenSUSE 16.0 対応の追加
  • src/libraries/System.Net.Security/tests/UnitTests/NegotiateAuthenticationTests.cs: テスト設定の軽微な調整

パフォーマンスへの影響

影響なし。インフラストラクチャのテスト環境更新のみであり、ランタイム実装やコンパイラ、ライブラリの動作には直接的な影響はありません。

関連Issue

なし（PR本文には Issue 番号の記載がありません）

その他

  • リスク評価: 低。確立されたプラットフォーム バージョン更新パターンに従っており、Helix インフラストラクチャ チームがコンテナ イメージを保守しています
  • 後方互換性: 破壊的変更なし。既存のテスト実行フローに影響を与えない標準的な環境アップグレードです
  • 検証方法: CI パイプライン実行により更新されたプラットフォームで自動検証されます

#121429 [release/9.0] Update dependencies from dotnet/arcade

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2025年11月07日 02:05:02(UTC)
  • マージ日時: 2026年01月21日 23:33:47(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPRは dotnet/arcade リポジトリの依存パッケージを更新するドットネットマエストロによる自動更新です。Arcade SDK およびビルドタスク群を 9.0.0-beta.25626.6 から 9.0.0-beta.26070.1 へ、テストフレームワークを 2.9.0-beta.25626.6 から 2.9.0-beta.26070.1 へ更新し、.NET SDK を 9.0.113 に統一します。

変更内容

  • eng/Version.Details.xml: 19種類の Arcade 関連パッケージのバージョンを一括更新（9.0.0-beta.25626.6 → 9.0.0-beta.26070.1、2.9.0-beta.25626.6 → 2.9.0-beta.26070.1）
  • eng/Versions.props: SDK バージョンおよびツール dotnet バージョンを 9.0.113 に統一、Arcade.Sdk および XUnitAssert/XUnitConsoleRunner のバージョン定義を更新
  • global.json: .NET SDK バージョンを 9.0.113 に更新
  • ビルドテンプレート群: publish-build-assets.yml、source-build.yml、post-build.yml、pool-providers.yml の微細な設定調整（1〜2行の差分）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このPRは release/9.0 ブランチへのドットネットマエストロ自動更新です。2026年1月20日時点の Arcade コミット 9b9436a55a を基準としており、ビルド、パッケージ管理、テスト実行、API 生成など .NET ランタイムの構築に必要な各種ツールの統一的なアップデートを実施しています。

#120306 Add IReadOnlySet support to System.Text.Json

  • 作成者: @sander1095
  • 作成日時: 2025年10月01日 20:35:27(UTC)
  • マージ日時: 2026年01月21日 17:21:40(UTC)
  • ラベル: area-System.Text.Json community-contribution

概要

このPRはSystem.Text.JsonライブラリにIReadOnlySet<T>のシリアライズおよびデシリアライズ機能を追加します。ISet<T>やICollection<T>など他のコレクションインターフェースと同じ方法でIReadOnlySet<T>を認識・変換できるようになります。また、例外ヘルパーメソッド名のタイポ修正も含まれます。

// 使用例
var options = new JsonSerializerOptions();
var jsonString = JsonSerializer.Serialize(myReadOnlySet, options);
var deserialized = JsonSerializer.Deserialize<IReadOnlySet<int>>(jsonString);

変更内容

  • 新規コンバーター追加: IReadOnlySetOfTConverter.cs (47行追加) - IReadOnlySet<T>専用の変換ロジック
  • コンバーターファクトリ更新: IEnumerableConverterFactory.cs でIReadOnlySet<T>のサポート追加
  • 型認識: CollectionType.csとKnownTypeSymbols.csでIReadOnlySet<T>を既知のコレクション型として登録
  • メタデータサービス: JsonMetadataServices.Collections.csに専用メソッド追加
  • テスト追加: 読み書きテスト (100+131行)、ジェネリックコレクションテスト (311行)、ポリモーフィックテストなど
  • タイポ修正: ReturnsJsonConverterFactorty → ReturnsJsonConverterFactory (JsonConverterFactory.csとThrowHelper.Serialization.cs)

パフォーマンスへの影響

影響なし。既存の他のコレクション型（ISet<T>）と同様の実装パターンに従っており、専用コンバーターにより効率的なシリアライズ/デシリアライズが実現されます。

関連Issue

#91875

その他

  • Source Generator対応：ジェネレータコード（JsonSourceGenerator.Emitter.cs、JsonSourceGenerator.Parser.cs）も更新され、AOT環境でのサポートも確保
  • 破壊的変更なし：新機能の追加のため、既存コードの互換性は保持
  • 包括的なテストカバレッジ：汎用読み書きテスト、Creation Handling、参照ハンドリング、イミュータブルコレクション、ポリモーフィックテストなど多岐にわたるテストが追加

#118415 [EventPipe] Remove thread lock and cleanup ThreadSessionState lifecycle

  • 作成者: @mdh1418
  • 作成日時: 2025年08月05日 22:00:15(UTC)
  • マージ日時: 2026年01月21日 15:52:25(UTC)
  • ラベル: area-Tracing-coreclr

概要

EventPipeの複雑な二重ロック同期スキーム（スレッドロック + buffer_managerロック）を廃止し、単一のbuffer_managerロックに統一。ThreadSessionStateのライフサイクル管理を改善し、メモリリークを防止します。

変更内容

  • スレッドロック廃止: スレッドリストとsession_state スロット更新をbuffer_managerロック下で原子的に実行
  • ThreadSessionState クリーンアップ: イベント読み込みロジックに統合し、メモリリークを修正
  • SequencePoint追跡最適化: EventPipeThreadSequencePointTrackState列挙型を追加し、最短イベントを保持していないスレッドの反復を回避
  • 同期モデル簡素化: クロスロック競合条件を排除し、race conditionを削減

主要変更ファイル: ep-buffer-manager.c（+393/-409）、ep-thread.c（+72/-95）、ep-session.c（+26/-54）

パフォーマンスへの影響

改善点:

  • Native InProc セッションで特に高スレッド×高例外/スレッドシナリオでドロップイベント数が大幅に削減
  • 長時間実行セッションでのメモリ使用量を削減（テスト結果: RSS 51.7～60.3MiB で安定化）
  • CPU使用率の効率化（100～119% の範囲で安定）

IPC Streaming での影響:

  • 高スレッド×高例外/スレッド時に約0.8%のイベント読み込み低下（許容範囲）
  • 全体的には安定した動作

関連Issue

#111368

その他

  • 互換性: 内部実装の変更であり、公開APIへの影響なし
  • セキュリティ: race condition排除により、同期関連の脆弱性が軽減
  • テスト: 元の再現シナリオ（500万例外、5000短時間スレッド）で検証済み