Pull Request on 2026年01月23日

eng/Version.Details.xml: System.ServiceModel.Primitives 依存関係エントリ（バージョン 4.9.0-rc2.21473.1）を dotnet/wcf ソースから削除
eng/Version.Details.props: SystemServiceModelPrimitivesPackageVersion および SystemServiceModelPrimitivesVersion プロパティ定義を削除（計4行削除）

パフォーマンスへの影響

影響なし

その他

この変更は依存関係管理ファイルの整理に関するもので、公開API や実装コードへの変更はありません。Windows Compatibility Pack との互換性については既に不要となっているため、破壊的変更の懸念はありません。

#123541 Mark new userevents tests as native AOT incompatible

作成者: @MichalStrehovsky
作成日時: 2026年01月23日 12:00:25(UTC)
マージ日時: 2026年01月23日 21:42:24(UTC)
ラベル: area-Tracing-coreclr

概要

Native AOT コンパイルでクラッシュしている User Events テストスイートを Native AOT 非互換として正式にマークしました。テスト実行時に System.ArgumentNullException が発生していた問題に対応するため、Directory.Build.props ファイルを追加して NativeAotIncompatible=true を設定しています。

変更内容

src/tests/tracing/userevents/Directory.Build.props: 新規作成（8行追加）
- User Events テストスイート全体に対して NativeAotIncompatible=true プロパティを設定
- このプロパティにより、Native AOT テスト実行環境からこれらのテストが除外される

パフォーマンスへの影響

影響なし。この変更はテストスイートのマーキングのみで、ランタイムコードの変更ではありません。

その他

互換性への影響: Native AOT 環境でのテスト実行は除外されますが、JIT コンパイル環境でのテスト実行は継続されます
問題の原因: User Events テストランナーが Native AOT 環境で必要なパス情報を解決できないことが根本原因（UserEventsTestRunner.ResolveRecordTracePath() で null パラメータが発生）
今後の対応: テストの Native AOT 対応が必要な場合は、テストランナーの実装改善が別途必要

#123539 Run OneLocBuild and SourceIndex on schedule instead of every commit in runtime-official.yml

作成者: @akoeplinger
作成日時: 2026年01月23日 11:45:33(UTC)
マージ日時: 2026年01月23日 11:47:43(UTC)
ラベル: area-Infrastructure

概要

runtime-official.yml CI パイプラインの最適化により、OneLocBuild と SourceIndex を毎コミット実行から定期スケジュール実行（日次）に変更。assetless ビルドの導入によりパイプライン実行時間が短縮されたため、毎回これらの操作を実行する必要がなくなり、CI リソースの節約を実現。

変更内容

ファイル: eng/pipelines/runtime-official.yml
- 毎日 9:00 AM UTC にメインブランチで実行される定期スケジュールトリガーを追加
- Localization および Source_Index ステージの実行条件を変更し、スケジュール実行またはマニュアル実行時のみ実行するように制限

パフォーマンスへの影響

CI リソース削減：

OneLocBuild と SourceIndex は日次更新のみであるため、毎コミット実行は不必要な処理オーバーヘッド
スケジュール実行に制限することで、日々のコミットに対する CI ジョブ数を削減
assetless ビルド導入後、パイプライン全体の実行時間が大幅に短縮されたため、リソース最適化の効果が顕著

その他

変更は breaking change ではなく、純粋な CI 最適化
OneLocBuild（ローカライゼーション）と SourceIndex（ソースコードインデックス）は開発者向けツール/機能であり、日次更新で十分であることが根拠
マニュアルトリガーのサポートにより、必要に応じて即座に実行可能な柔軟性も確保

#123536 SPMI: Tolerate missing getContinuationType calls

作成者: @jakobbotsch
作成日時: 2026年01月23日 10:02:00(UTC)
マージ日時: 2026年01月23日 14:23:17(UTC)
ラベル: area-CodeGen-coreclr

概要

SuperPMI（.NETランタイムのJIT性能測定ツール）の改善で、getContinuationType呼び出しが記録にない場合の処理を強化しました。非同期処理関連の変更時に、継続型レイアウトが見つからないシナリオに対して、合成された仮のクラスハンドルを返すことで、不要な「コンテキスト欠落」エラーを回避できます。

// 疑似継続型ハンドルを使用した処理例
// repGetContinuationType が見つからない場合、仮のハンドルを返す
CORINFO_CLASS_HANDLE pseudoHandle = /* synthetic handle */;

変更内容

methodcontext.cpp (+31/-8)
- repGetContinuationTypeメソッドに記録キーが存在しない場合のフォールバック処理を追加
- 疑似継続型CORINFO_CLASS_HANDLE値を導入
- repEmbedClassHandleメソッドで疑似ハンドルの特別処理を実装し、埋め込み動作を一貫性保つ

パフォーマンスへの影響

影響なし。本変更はテスト・計測ツール（SuperPMI）の内部実装であり、ランタイムのパフォーマンスには直接影響しません。

その他

背景: 非同期処理の変更により新しいライブ状態が追加される場合、異なる継続型が必要になるため、getContinuationTypeの不一致は一般的なシナリオです
技術的観点: JITが返す継続型ハンドルは実質的に不透明であり、コードストリームへの埋め込みのみが必要なため、合成ハンドルで代替可能です
互換性: 内部実装の変更のため、公開APIへの影響なし

#123535 Avoid C4319 build warnings in libunwind (#122179)

作成者: @ViktorHofer
作成日時: 2026年01月23日 09:56:00(UTC)
マージ日時: 2026年01月23日 12:17:16(UTC)
ラベル: needs-area-label

概要

VS 2026のコンパイラ警告C4319を解消するため、libunwindのUNW_ALIGNマクロに明示的なsize_t型キャストを追加しました。unsigned longからsize_tへのゼロ拡張に関する警告を修正し、Windows環境での整合性を改善するアップストリーム修正のバックポートです。

変更内容

src/native/external/libunwind/include/libunwind_i.h: UNW_ALIGNマクロをunsigned long型リテラルから明示的なsize_t型キャストに変更
src/native/external/libunwind-version.txt: アップストリームPR #931の適用を記録

パフォーマンスへの影響

影響なし。本変更はコンパイル時の警告解消に限定されており、ランタイム動作やパフォーマンスへの影響はありません。

その他

本変更はVS 2026の更新されたMSVCアナライザー規則に対応するための修正です。release/9.0ブランチへの適用により、新しいバージョンのVisual Studioでのビルド互換性が確保されます。

#123530 Disable StringBuilder marshalling tests on native AOT

作成者: @MichalStrehovsky
作成日時: 2026年01月23日 06:54:08(UTC)
マージ日時: 2026年01月23日 21:43:22(UTC)
ラベル: needs-area-label

概要

Native AOT環境でのStringBuilder marshalling テストの失敗に対応するため、3つのテストメソッド（ByValue、ByRef、ReversePInvoke）にActiveIssue属性を追加して、Native AOT環境での実行をスキップするようにしました。これらのテストは PR #123112 により outerloop priority tracking の修正後に実行されるようになったことが原因です。

変更内容

src/tests/Interop/StringMarshalling/Common/StringBuilderTests.cs
- 3つのStringBuilder marshalling テストメソッドにActiveIssue属性を追加
- 対応するIssue #123529 を参照して Native AOT での実行をスキップ

パフォーマンスへの影響

影響なし

その他

本PR は Native AOT 環境でのテスト失敗への一時的な対応です
根本原因の修正は Issue #123529 で追跡中です
このPRは ILC contribution チーム（@dotnet/ilc-contrib）に関連した変更です

#123528 Update native AOT ActiveIssue on NegotiateAuthenticationTests

作成者: @MichalStrehovsky
作成日時: 2026年01月23日 06:39:09(UTC)
マージ日時: 2026年01月23日 12:16:38(UTC)
ラベル: area-System.Net.Security

概要

Native AOT + Linux環境でNegotiateAuthenticationTests全体がクラッシュする問題に対応するため、ActiveIssue属性をテストメソッドレベルからクラスレベルに変更しました。当初は特定のテスト（Package_Unsupported_NTLM）のみが問題だと思われていましたが、実際にはテストクラス全体が影響を受けることが判明したため、スキップの対象範囲を拡大しています。

変更内容

src/libraries/System.Net.Security/tests/UnitTests/NegotiateAuthenticationTests.cs
- ActiveIssue属性の適用範囲をメソッドレベルからクラスレベルに変更
- Native AOT + Linux環境でのテストスキップ対象をテストクラス全体に拡大

パフォーマンスへの影響

影響なし（テストスキップの範囲変更のため、ランタイムパフォーマンスへの影響なし）

その他

本修正はNative AOT環境でのLinux上でのネゴシエーション認証テストの問題を回避するものです。テストスキップの範囲拡大により、Native AOT + Linuxコンビネーションでの未検証の動作を一時的に除外します。根本的な問題解決ではなく、テスト実行環境への対応です。

#123525 Remove unused code from CoreCLR utilcode

作成者: @Copilot
作成日時: 2026年01月23日 03:46:49(UTC)
マージ日時: 2026年01月23日 15:47:06(UTC)
ラベル: 指定なし

概要

CoreCLRのutilcodeから使用されていない関数とクラスを削除するコード整理PRです。ClrVirtualAllocAligned関数、ConfigStringクラス、ConfigMethodSetクラスを削除し、メンテナンス対象を削減しています。ConfigDWORDクラスは引き続き使用されているため保持されます。

変更内容

src/coreclr/inc/utilcode.h: ClrVirtualAllocAligned宣言、ConfigStringクラス宣言、ConfigMethodSetクラス宣言を削除（-69行）
src/coreclr/utilcode/util.cpp: 上記3つの実装を削除。ClrVirtualAllocAligned内のUNIXTODOコメントも含めて削除（-99行）

削除対象の技術詳細:

ClrVirtualAllocAligned: メモリアライメント機能を提供する内部API（呼び出し箇所なし）
ConfigString: 設定文字列ラッパークラス（インスタンス化されていない）
ConfigMethodSet: 設定メソッドセットクラス（init()とcontains()オーバーロード、未使用）

パフォーマンスへの影響

影響なし。削除コードはコンパイル時の不要なシンボル処理が削減される可能性がありますが、実行時パフォーマンスへの直接的な影響はありません。

その他

grepによる検証済み：削除対象の全項目は宣言/実装箇所のみに存在することを確認
Debug/Release両方の構成でビルド成功を確認
ConfigDWORDクラスは複数の場所（rejit.inl、debug.cpp、gccover.cpp等）で積極的に使用されているため保持

#123522 [Wasm RyuJit] Fix emission of block and label instructions

作成者: @AndyAyersMS
作成日時: 2026年01月23日 02:22:02(UTC)
マージ日時: 2026年01月23日 22:25:21(UTC)
ラベル: area-CodeGen-coreclr

概要

WebAssembly RyuJIT コンパイラで、block および loop 命令の emission 時に必須の型フィールド（block type byte）が欠落していた問題を修正しました。新しい emitIns_B ヘルパーメソッドを追加し、これらの構造化制御フロー命令が正しく型情報を含めて emission されるようにしました。

変更内容

src/coreclr/jit/emitwasm.h: Wasm block スタイル命令用の新しい emitIns_B エントリポイントを宣言
src/coreclr/jit/emitwasm.cpp: emitIns_B を実装し、IF_BLOCK 形式を使用してエンコーダに block-type byte（現在は void で固定）を出力させる
src/coreclr/jit/codegenwasm.cpp: genEmitStartBlock で INS_block/INS_loop を emitIns_B 経由で emission するよう更新

パフォーマンスへの影響

影響なし。本修正は WebAssembly 仕様に準拠した正しい命令 encoding を保証するもので、パフォーマンスへの直接的な影響はありません。

その他

本修正は WebAssembly RyuJIT の構造化制御フロー命令 emission の正確性に関する修正です。従来は generic な instGen を使用していたため型フィールドが省略されていましたが、専用の emitIns_B を用いることで IF_BLOCK 形式を明示的に指定し、正しく型情報を含めることができます。ラベル emission は引き続き emitIns_J と IF_RAW_ULEB128 経由で行われ、br_table ラベルの encoding の正確性は維持されます。

#123520 [release/10.0] Fix regression caused by special marker type optimization (#123413)

作成者: @davidwrighton
作成日時: 2026年01月23日 00:32:57(UTC)
マージ日時: 2026年01月23日 23:28:05(UTC)
ラベル: Servicing-approved area-TypeSystem-coreclr

概要

PR #120712で導入された「特殊マーカー型」インターフェースマップ最適化による2つの回帰を修正するバックポートです。主な修正は、インターフェース展開ロジックの完全な実装と、ジェネリック型パラメータ数の上限チェック(MaxGenericParametersForSpecialMarkerType)の忘却箇所の対応です。特にVB.NETコンパイラのメタデータ生成パターンで問題が顕在化しています。

変更内容

clsload.cpp/hpp: 特殊マーカー型の適格性判定を一元化するEligibleForSpecialMarkerTypeUsageヘルパー関数を実装
methodtablebuilder.cpp: インターフェースマップ構築時に特殊マーカー型の複数の組み合わせケースに対応。フォールバック処理を追加
siginfo.cpp: 署名/型ロード処理で一元化された適格性チェックを適用
typehandle.h: Instantiation::ContainsAllOneTypeにDAC契約注釈を追加
回帰テスト: GitHub_123254(VB.NET)とGitHub_123318(C#)の回帰テストを新規追加

パフォーマンスへの影響

影響なし。本修正は回帰バグの修正であり、PR #120712で導入された起動時間改善の最適化パスを正しく機能させるものです。不正な特殊マーカー型シナリオ時には安全にフォールバック処理が発動されます。

その他

顧客影響: #123254はほぼVB.NET顧客が対象。#123318はC#を含む大量のジェネリックパラメータ型を利用する顧客に影響
リスク評価: 低。本修正前の実装は機能していなかったため、修正により悪化することはない
テスト戦略: 顧客環境での再現テストに加え、新規回帰テストを追加。VB.NETテスト用にDefineConstantsの区切り文字フォーマットも調整

#123519 [clr-interp] Handle unmanaged thiscall on Windows Arm64

作成者: @davidwrighton
作成日時: 2026年01月22日 23:55:56(UTC)
マージ日時: 2026年01月23日 22:31:43(UTC)
ラベル: area-CodeGen-Interpreter-coreclr

概要

Windows Arm64上のアンマネージドC++メンバー関数（thiscall）呼び出しに対応するため、戻り値バッファの引き渡しメカニズムを修正しました。Windows Arm64では、戻り値バッファが通常のX8レジスタではなく、第2引数レジスタ（X1、thisが存在する場合）で渡される特異な呼び出し規約に対応しています。

変更内容

src/coreclr/vm/callingconvention.h: Windows Arm64向けthiscall呼び出しイテレータの専門化を追加。IsRetBuffPassedAsFirstArg()メソッドを導入
src/coreclr/vm/callstubgenerator.h: Windows Arm64専用のReturnTypeBuffArg2列挙値を追加（戻り値バッファがX1で渡される場合を表現）
src/coreclr/vm/callstubgenerator.cpp: Windows Arm64のthiscall用ArgIterator選択ロジックと、CallJittedMethodRetBuffX1/InterpreterStubRetBuffX1へのルーティング処理を追加
src/coreclr/vm/arm64/asmhelpers.asm: X1経由の戻り値バッファ渡しに対応するアセンブリスタブ（InterpreterStubRetBuffX1、CallJittedMethodRetBuffX1）を追加
src/coreclr/vm/reflectioninvocation.cpp: IsRetBuffPassedAsFirstArg()実装を追加

パフォーマンスへの影響

影響なし。本変更は特定プラットフォーム向けの呼び出し規約対応であり、その他のプラットフォームのコード生成パスには影響しません。

その他

本変更は互換性に関わる修正です。Windows Arm64上でのアンマネージドコード相互運用（P/Invoke、COM相互運用）における戻り値の正確な引き渡しを確保するもので、既存コードの動作に影響する可能性があります。

#123513 [clr-interp] Fix jmp instruction to tolerate the call.tail opcode failing to actually tail call

作成者: @davidwrighton
作成日時: 2026年01月22日 22:37:44(UTC)
マージ日時: 2026年01月23日 19:23:08(UTC)
ラベル: area-CodeGen-Interpreter-coreclr

概要

CLR インタープリタの CEE_JMP 命令処理を修正し、call.tail オペコードが実際にはテール呼び出しを実行しない場合にも対応するようにしました。リターン処理ロジックを EmitRet ヘルパー関数に統合し、CEE_RET と CEE_JMP の両方から呼び出すことで、テール呼び出し失敗時にも無効なコード実行を防ぐようになります。これにより Windows Arm64 での P/Invoke ジャンプ/テールコール関連テストが修正されます。

変更内容

src/coreclr/interpreter/compiler.h
- EmitRet(CORINFO_METHOD_INFO* methodInfo) ヘルパーメソッドを新規追加（内部実装）
src/coreclr/interpreter/compiler.cpp
- EmitRet ヘルパーの実装：リターン生成ロジックを一箇所に集約
- CEE_RET 処理をリファクタリング：すべてのリターン関連コード生成を EmitRet に委譲
- CEE_JMP 処理の改善：
  - 同期化メソッドおよび非同期メソッドでの使用を禁止
  - テール呼び出し後に明示的な ret 命令を挿入し、テール呼び出しが失敗した場合でも有効な制御フロー（プログラムカウンタ調整とブロックリンク）を保証

パフォーマンスへの影響

影響なし。本変更は制御フロー正確性の確保が目的であり、パフォーマンスクリティカルなパスへの負荷増加はありません。テール呼び出し成功時の動作に変更はありません。

その他

修正対象のテストケース：
- JIT/Directed/pinvoke/jump
- JIT/Directed/pinvoke/tail_pinvoke
IP（命令ポインタ）調整ロジックは CEE_RET ハンドリング内に一本化され、EmitRet では実施されないよう整理されました。
Windows Arm64 プラットフォームにおいて call.tail の動作が確定的でない点に対応した修正です。

#123505 Add package readmes to illink NuGet packages stating SDK-only support

作成者: @Copilot
作成日時: 2026年01月22日 18:00:44(UTC)
マージ日時: 2026年01月23日 01:00:34(UTC)
ラベル: linkable-framework

概要

Microsoft.NET.ILLink と Microsoft.NET.ILLink.Tasks NuGetパッケージに対して、SDK内部専用パッケージであることを明記するPACKAGE.mdファイルを追加しました。これらのパッケージは直接参照すべきではなく、SDKを通じてのみ使用されるべきであることをユーザーに明確に伝えます。

変更内容

PACKAGE.md ファイルの追加: src/tools/illink/src/linker/PACKAGE.md と src/tools/illink/src/ILLink.Tasks/PACKAGE.md を新規作成。「このパッケージを直接参照しないでください」という警告文とトリミング関連ドキュメントリンクを記載
プロジェクトファイルの修正:
- Mono.Linker.csproj: EnableDefaultPackageReadmeFile=true を追加してパッケージ内にreadmeを含める
- ILLink.Tasks.csproj: EnableDefaultPackageReadmeFile=false を削除してreadme機能を有効化

パフォーマンスへの影響

影響なし

その他

このPRは、他のSDK内部パッケージ（例：Microsoft.NETCore.App）と同じ構造のPACKAGE.mdを採用しており、リポジトリ全体で一貫した向け方針を維持しています。ユーザーがNuGetから直接これらのパッケージを利用しようとした場合、パッケージメタデータに明確な警告が表示されるようになります。

#123502 Fix hash collision in TypeMapLazyDictionary causing non-deterministic ArgumentException

作成者: @Copilot
作成日時: 2026年01月22日 17:16:22(UTC)
マージ日時: 2026年01月23日 16:57:36(UTC)
ラベル: 指定なし

概要

TypeMapping.GetOrCreateExternalTypeMapping で発生していた非決定的な ArgumentException を修正しました。異なる型名が同一の GetHashCode() 値を持つ場合（例："Windows.Media.Devices.Core.FrameFlashControl" と "Windows.Security.Credentials.PasswordCredential"）にハッシュ衝突が発生していたのが原因です。LazyExternalTypeDictionary を Dictionary<int, DelayedType> から Dictionary<string, DelayedType> に変更し、ハッシュ値ではなく文字列キーそのものを使用することで解決しました。

// 修正前: ハッシュ衝突の可能性あり
Dictionary<int, DelayedType> _lazyData;  // int = key.GetHashCode()

// 修正後: 衝突なし
Dictionary<string, DelayedType> _lazyData;  // 文字列キーを直接使用

変更内容

src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/TypeMapLazyDictionary.cs

LazyExternalTypeDictionary の内部辞書をハッシュコード（int）キーから文字列キーに変更
ComputeHashCode メソッドを削除
TryGetOrLoadType と Add メソッドで文字列キーを直接使用するよう調整

パフォーマンスへの影響

影響なし。むしろ改善の可能性があります。ハッシュコード衝突に伴う重複キー例外の処理オーバーヘッドが排除され、文字列キーによる直接参照は Dictionary のネイティブ実装で最適化されています。

その他

既存テスト範囲で十分な検証が可能
同様の衝突安全なアプローチは既に LazyProxyTypeDictionary で実装済み
CoreCLR のみで発生していた非決定的な挙動が対象（AOT は未影響）

#123458 [release/9.0] Change pool in evaluate-paths

作成者: @github-actions[bot]
作成日時: 2026年01月21日 23:39:16(UTC)
マージ日時: 2026年01月23日 17:30:30(UTC)
ラベル: Servicing-approved area-Infrastructure

概要

release/9.0ブランチへのバックポート変更です。evaluate-paths-jobパイプラインの設定でプール（実行環境）の構成を変更しています。これはCI/CDパイプラインの実行環境最適化に関連する変更です。

変更内容

eng/pipelines/common/evaluate-paths-job.yml: パイプラインジョブ設定でプール定義を更新（+7行、-1行）

パフォーマンスへの影響

CI/CDパイプラインの実行環境構成の変更であるため、ビルドまたはテスト実行の効率に影響する可能性があります。ただし、具体的なパフォーマンス数値はPR情報に記載されていません。

その他

本変更は自動化されたバックポートプロセス（github-actions[bot]）により実施されたものです
変更内容の具体的な詳細（どのプール設定がどのように変更されたか）はPR説明に記載されていないため、#123453を参照する必要があります
作成者による詳細なテスト方法、カスタマーへの影響、リスク評価の記入がないため、本変更は軽微な設定変更と考えられます

#123428 Make order of generated logger items stable.

作成者: @cincuranet
作成日時: 2026年01月21日 11:13:21(UTC)
マージ日時: 2026年01月23日 13:26:54(UTC)
ラベル: area-Extensions-Logging source-generator

概要

ロガーメッセージジェネレータの生成されたクラスの出力順序を安定化させました。namespace→name の順でソートして出力することで、ビルド結果の非決定性を排除し、再現可能なビルドを実現します。これにより、同じソースコードから常に同じ生成コードが出力されるようになります。

変更内容

LoggerMessageGenerator.Parser.cs: Emit メソッドを修正し、コード生成前にロガークラスを namespace と name でソート
TestWithMultipleClassesStableOrder.generated.txt: 安定した出力順序を検証するためのベースラインテストファイルを追加（57行）
LoggerMessageGeneratorEmitterTests.cs: 複数クラスが安定した順序で生成されることを検証するテストケースを追加（25行）

パフォーマンスへの影響

影響なし。ソート処理は生成時のみの操作であり、ランタイムパフォーマンスへの影響はありません。ビルド時間への影響も無視できる水準です。

その他

このPRは再現可能なビルド（reproducible builds）に対応するための変更です。複数のロガークラスが存在する場合、ハッシュテーブルのイテレーション順序に依存していた非決定性が解決されます。CI/CD パイプラインやビルド検証プロセスの信頼性が向上します。

#123403 Use existing Base64 helpers for Base64FormattingOptions.InsertLineBreaks

作成者: @MihaZupan
作成日時: 2026年01月20日 20:45:39(UTC)
マージ日時: 2026年01月23日 22:32:11(UTC)
ラベル: area-System.Memory reduce-unsafe

概要

Base64エンコーディングで改行挿入（Base64FormattingOptions.InsertLineBreaks）を行う際、既存のBase64.EncodeToCharsヘルパーを利用するようにリファクタリングしました。不安全なポインタベースの実装から安全なspan操作への変更により、30バイト以上の入力では性能が向上（最大47%削減）します。10～20バイトのごく小さい入力では軽微な性能低下（9～56%増加）がありますが、全体としては改善されています。

変更内容

src/libraries/System.Private.CoreLib/src/System/Convert.cs (+23/-62)
- 手動でのBase64エンコーディングループをBase64.EncodeToChars呼び出しに置き換え
- 改行挿入ロジックを57バイト単位（76 Base64文字）のチャンク処理に簡潔化
- 不安全なポインタ操作からspanベースの安全操作へ移行
- ToBase64Stringをstring.Createで効率的に実装

パフォーマンスへの影響

改善点：

30バイト以上の入力で大幅改善：26～47%の性能向上
- 1000バイト：477.4ns → 251.1ns（53%削減）
- 100バイト：50.0ns → 28.5ns（57%削減）
- 40バイト：22.5ns → 12.9ns（42%削減）

懸念点：

ごく小さい入力（10～20バイト）で軽微な性能低下
- 10バイト：7.8ns → 12.2ns（56%増加）
- 20バイト：12.8ns → 14.0ns（9%増加）

実装の単純化と中～大規模データの処理性能向上がトレードオフですが、一般的な使用シナリオではメリットが大きいと考えられます。

その他

不安全なコード（unsafe）の削減により、保守性とセキュリティが向上しています。既存のBase64.EncodeToCharsヘルパーを活用することで、コード重複を排除し、実装の一貫性を強化しています。

#123400 [browser][coreCLR] HTTP and WS client implementation in JS

作成者: @pavelsavara
作成日時: 2026年01月20日 19:48:35(UTC)
マージ日時: 2026年01月23日 12:19:42(UTC)
ラベル: arch-wasm area-System.Runtime.InteropServices.JavaScript os-browser

概要

このPRではMonoからHTTPおよびWebSocket JavaScriptクライアント実装をCoreCLRに移植しました。ブラウザベースのWASM応用でネットワーク機能が利用できるようになります。WebSocketのクローズステータスプロパティ名をJavaScript命名規約に準拠させ、null promiseハンドリングのバグを修正し、タイマー管理機構を拡張しました。

// C#側：WASM環境でHTTPやWebSocket通信が利用可能に
using System.Net.Http;
using System.Net.WebSockets;

変更内容

JavaScriptモジュール追加:

web-socket.ts (+503行): WebSocketクライアント実装（接続管理、メッセージバッファリング、エラーハンドリング）
http.ts (+299行): HTTPクライアント実装（ストリーミング対応、Fetch API ラッパー）
queue.ts (+72行): 汎用キューデータ構造
scheduling.ts (+61行): Chromiumブラウザのタイマースロットリング回避機構
utils.ts (+11行): UTF-8デコーダー追加

バグ修正・改善:

marshal-to-cs.ts: null promiseで実行時エラーが発生していた問題を修正
host.ts: abortTimers → abortBackgroundTimersへ名称変更、runBackgroundTimersを追加
exit.ts: タイマークリーンアップ順序を最適化（abortInteropTimersとabortBackgroundTimersを早期呼び出し）

C#コード更新:

BrowserInterop.cs: WebSocketプロパティ名をcloseStatus/closeStatusDescriptionに統一
BrowserWebSockets: テスト環境にHTTP/WebSocketテストを追加

パフォーマンスへの影響

改善:

Chromiumブラウザでのタイマースロットリング回避により、WebSocket接続の応答性が向上
バックグラウンドタイマー管理により、不要なタイマー処理を削減可能

注意点:

新たなJavaScriptモジュール（合計~1000行超）が追加されるため、初期バンドルサイズ増加の可能性

その他

JavaScriptの命名規約統一（snake_case → camelCase）により、他言語間の相互運用性が改善
Mono実装からのポーティングのため、既に検証済みのコード品質が保証される
CMakeLists.txtおよびエクスポートテーブルが更新され、ビルドシステムに統合

#123341 [browser] Check unique relative path for assemblies

作成者: @maraf
作成日時: 2026年01月19日 11:02:05(UTC)
マージ日時: 2026年01月23日 09:50:29(UTC)
ラベル: arch-wasm area-Build-mono os-browser

概要

WebAssembly ビルドプロセスの回帰問題を修正するPRです。NuGetパッケージから複数のカルチャを持つサテライトアセンブリが、重複ファイルとして誤くフラグされる問題を解決しました。サテライトアセンブリはカルチャ固有のサブディレクトリに配置されるため、メインフレームワークフォルダのアセンブリに対してのみ適用される一意ファイル名チェックをバイパスするよう修正しています。

変更内容

ファイル	主な変更内容
`ComputeWasmBuildAssets.cs`	サテライトアセンブリの一意ファイル名チェックをスキップするロジックを追加
`SatelliteLoadingTests.cs`	フランス語ロケール用テスト追加およびパッケージソースのサテライトアセンブリテスト追加
`ResourceLibrary.csproj`	Microsoft.CodeAnalysis.CSharp パッケージの条件付き参照追加（サテライトアセンブリテスト用）
`words.fr-FR.resx`	フランス語ローカライズリソースファイルを新規作成
`SatelliteAssembliesTest.cs` / `ResourceAccessor.cs`	フランス語カルチャテスト出力対応

パフォーマンスへの影響

影響なし。本変更はビルド処理のロジック修正であり、ランタイム実行時のパフォーマンスには影響しません。

その他

本修正により、複数のカルチャに対応したサテライトアセンブリを含むNuGetパッケージを参照プロジェクトまたはPackageReferencesで使用する場合、ビルド時の重複ファイルエラーが発生しなくなります。テスト範囲は参照プロジェクトとPackageReference双方をカバーしています。

#123317 [RuntimeAsync] Stop emitting modreqs into signatures of async variants.

作成者: @VSadov
作成日時: 2026年01月17日 20:00:41(UTC)
マージ日時: 2026年01月23日 04:14:58(UTC)
ラベル: area-VM-coreclr runtime-async

概要

RuntimeAsync機能における非同期メソッド変種のシグネチャからmodreqの生成を廃止し、代わりにAsyncVariantKind列挙型をMethodSignatureに追加して、非同期変種の種別（Task/ValueTask）を明示的に追跡する変更です。これにより、Task<int> M()とValueTask<int> M()の非同期変種を同じスコープ内で区別でき、シグネチャの曖昧性を解決しています。

enum AsyncVariantKind
{
    None      = 0,  // 非同期変種ではない
    Task      = 1,  // Task[<T>]返却メソッド用の非同期変種
    ValueTask = 2   // ValueTask[<T>]返却メソッド用の非同期変種
}

変更内容

methodtablebuilder.h: AsyncVariantKind列挙型を追加、MethodSignatureコンストラクタを拡張して非同期変種の種別を保持
methodtablebuilder.cpp: SameAsyncVariantKind()チェック実装、シグネチャ等値性チェックに統合、modreqを削除した簡潔なシグネチャ構築に変更
method.hpp: IsAsyncVariantForValueTaskフラグとIsAsyncVariantForValueTaskReturningMethod()メソッドを追加、modreq削除に関するコメント更新
asyncthunks.cpp: IsValueTaskAsyncThunk()を廃止し、IsAsyncVariantForValueTaskReturningMethod()に置き換え

パフォーマンスへの影響

影響なし。変更は実行時の動作を変更するものではなく、メタデータ生成時のシグネチャ管理方式の改善です。

その他

互換性: この変更は内部実装（CLR VM層）に限定されており、公開APIの変更ではありません
バージョニング: modreq廃止により、IL層での署名が簡潔になり、今後のメタデータ処理が効率化される可能性があります
テストカバレッジ: オーバーライド、インターフェース実装、メソッドシグネチャマッチングが影響を受けるため、これらの領域でのテスト検証が重要です

#123255 DI container should respect generic constraints when resolving single instance

作成者: @rosebyte
作成日時: 2026年01月16日 11:06:11(UTC)
マージ日時: 2026年01月23日 12:16:23(UTC)
ラベル: area-Extensions-DependencyInjection

概要

DIコンテナのオープンジェネリック解決時に、制約が互換性のない最新登録をスキップし、以前の互換可能な登録にフォールバックしていた問題を修正。これにより、単一インスタンス解決時に「最後に登録されたもの勝ち」の原則が正しく適用されるようになりました。修正前は混乱を招く挙動を引き起こしていました。

変更内容

CallSiteFactory.cs: スロットカウンタの追跡ロジックを更新。最新登録に互換性のない制約がある場合でもカウンタをインクリメント
ServiceProviderContainerTests.cs: 列挙可能解決と単一サービス解決の両シナリオで修正動作を検証するテストケースを追加

パフォーマンスへの影響

影響なし（バグ修正で動作ロジックの改善のため）

その他

この修正はDI容器の一貫性に関わる重要な修正です。以前の動作では、互換性のない制約を持つ最新登録と互換可能な以前の登録が混在する場合、予期しない以前の実装が返される可能性がありました。修正後は、最新登録の制約が互換性なければ ArgumentException がスローされるようになり、意図しない動作を防止できます。

#123233 Add binary VN funcs to TryGetRangeFromAssertions

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

概要

JITの範囲チェック分析における二項演算（Add/Multiply）の処理を強化し、整数オーバーフロー時の動作を改善しました。TryGetRangeFromAssertions関数にオフセット削除ロジックを統合することで、アサーション基盤の範囲演算をSSAベースの処理と同等に改善しました。これにより、Issue #122288のオーバーフロー時の不正な範囲演算結果を修正します。

変更内容

ファイル	変更内容
src/coreclr/jit/rangecheck.h	RangeOps::AddとMultiplyメソッドをオーバーフロー検出対応に再構成。`CommutativeOperationWithConst`テンプレートを追加し、Add/Multiply処理を統一化
src/coreclr/jit/rangecheck.cpp	`TryGetRangeFromAssertions`にオフセット削除ロジックを抽出・統合。`TightenLimit`関数を追加
src/coreclr/jit/assertionprop.cpp	従来の直接的なADD処理をリファクタリング。範囲演算を`TryGetRangeFromAssertions`に委譲
src/tests/JIT/Regression/JitBlue/Runtime_122288/Runtime_122288.cs	Issue #122288のリグレッションテストを追加（オーバーフロー時の範囲分析動作検証）

パフォーマンスへの影響

コンパイル時間: 若干の増加の可能性あり。TryGetRangeFromAssertionsが複数のシナリオを統一処理するため、処理複雑度が増加 実行時パフォーマンス: 改善。より正確なオーバーフロー検出により、範囲チェックの枝刈りが増加し、より多くの分岐最適化が可能に メモリ: rangecheck.hの処理統合により、コード生成効率が向上

その他

Copilotのレビュー結果によると、4ファイル中4ファイルが確認済み
ホワイトスペース差分を無効にしてレビュー推奨（大規模リファクタリング）
SSAベースのGetRangeと同等の枝刈り機能を実装することで、JITの最適化精度を向上

#123196 Abstract away debug read/write channel.

作成者: @AaronRobinsonMSFT
作成日時: 2026年01月14日 22:18:10(UTC)
マージ日時: 2026年01月23日 15:49:15(UTC)
ラベル: area-Diagnostics-coreclr

概要

このPRはデバッグトランスポートレイヤーをリファクタリングし、TwoWayPipeの直接利用をIDebugChannel COM インターフェースで抽象化します。これにより関心の分離が向上し、将来的に異なるトランスポート実装への拡張が可能になります。

// 新しいインターフェース構造の例
interface IDebugChannel
{
    // 接続管理とread/write操作のメソッド
}

// 既存実装をラップ
class DbgTransportPipeChannel : IDebugChannel
{
    private TwoWayPipe pipe;
}

変更内容

dbgtransportsession.h/cpp: IDebugChannelインターフェース定義とDbgTransportPipeChannel実装クラスの追加、セッション管理の更新
debugger.h/cpp: InitIPCEventをpublicに変更、DebuggerStartUpヘルパークラスを導入してスタートアップ通知ロジックをカプセル化
processdescriptor.h: ヘッダーガード名の修正（_PROCESSCONTEXT_H → _PROCESSDESCRIPTOR_H_）
nativepipeline.h: CleanupTargetProcess()をすべてのプラットフォーム向けに純仮想メソッド化
windowspipeline.cpp, dbgtransportpipeline.cpp, process.cpp: CleanupTargetProcess()の統一実装と関連するプラットフォーム固有の条件コンパイルディレクティブの削除

パフォーマンスへの影響

影響なし。本変更はアーキテクチャのリファクタリングであり、デバッグトランスポート層の抽象化のみを目的としています。

その他

互換性: 内部実装の変更であり、パブリックAPIへの破壊的変更はありません
コード整理: クロスプラットフォームのCleanupTargetProcess()実装を統一することで、プラットフォーム固有のコード分岐を削減し保守性を向上

#123091 Add tar tests for >8GB file entries using simulated streams

作成者: @Copilot
作成日時: 2026年01月12日 17:06:26(UTC)
マージ日時: 2026年01月23日 13:05:25(UTC)
ラベル: area-System.Formats.Tar

概要

tar アーカイブにおいて 8GB を超える大容量ファイルエントリのハンドリングをテストするための自動テストスイートを追加しました。SimulatedDataStream と ConnectedStreams を活用して、CI 環境での大容量データテストをディスク領域やメモリ消費なしに実現します。ライター/リーダーの並列パターンで、実際のデータ実体化を回避しながら PAX および GNU フォーマットをテストしています。

変更内容

TarWriter.WriteEntry.LargeFiles.Tests.cs (新規)
- 並列ストリーミングテストクラスの実装（8GB + 1 バイトのエントリをテスト）
- PAX/GNU フォーマット × 同期/非同期 API = 8 つのテストシナリオ
- ライタータスクが SimulatedDataStream でダミーデータを生成、リーダータスクが ConnectedStreams.CreateUnidirectional() で消費
System.Formats.Tar.Tests.csproj
- ConnectedStreams、ArrayBuffer、MultiArrayBuffer、StreamBuffer の参照追加

パフォーマンスへの影響

影響なし。テスト実行時間は約 68 秒でディスク/メモリオーバーヘッドなし。既存の安定したユーティリティを利用しており、パフォーマンス関連の懸念はありません。

その他

本変更はテスト専用で、本体コード（プロダクション）の変更はありません。追加される依存ユーティリティはすべて既存の安定したテスト基盤であり、リスクは最小限です。

#120805 Fix primitive converters to honor JsonNumberHandling when obtained via GetConverter

作成者: @Copilot
作成日時: 2025年10月16日 15:21:23(UTC)
マージ日時: 2026年01月23日 00:24:51(UTC)
ラベル: area-System.Text.Json

概要

JsonSerializerOptions.GetConverter(Type)で取得した数値プリミティブコンバーター（Int32Converter等）が、公開メソッドRead()とWrite()でJsonNumberHandling設定を無視していた問題を修正しました。修正後は、例えばAllowReadingFromString設定で文字列形式の数値を正しく処理できるようになります。

var options = new JsonSerializerOptions { NumberHandling = JsonNumberHandling.AllowReadingFromString };
var converter = (JsonConverter<int>)options.GetConverter(typeof(int));
ReadOnlySpan<byte> json = "{\"x\": \"123\"}"u8;
var reader = new Utf8JsonReader(json);
reader.Read(); // StartObject
reader.Read(); // PropertyName
reader.Read(); // Number（実は文字列）
var result = converter.Read(ref reader, typeof(int), options); // ✅ 123に変換成功

変更内容

14個の数値プリミティブコンバーターを修正：

整数型（10種類）：ByteConverter、SByteConverter、Int16Converter、Int32Converter、Int64Converter、Int128Converter、UInt16Converter、UInt32Converter、UInt64Converter、UInt128Converter
浮動小数点型（4種類）：HalfConverter、SingleConverter、DoubleConverter、DecimalConverter

実装内容：

各コンバーターのRead()/Write()メソッドにJsonNumberHandlingチェックを追加
NumberHandlingがStrictでない場合、内部メソッドReadNumberWithCustomHandling()/WriteNumberWithCustomHandling()に委譲
Int128Converter、UInt128Converter、HalfConverterの無限再帰バグを修正（Read()の再帰呼び出しをReadCore()への直接呼び出しに変更）
テスト値の精度問題修正（浮動小数点値123.45f → 123.5fに統一）

テスト追加：

44個のGetConverter()固有テストを追加（全パス）
14個の数値型全てについてAllowReadingFromString、WriteAsString、AllowNamedFloatingPointLiteralsテストをカバー

パフォーマンスへの影響

影響なし

NumberHandlingがStrict（デフォルト）の場合、高速パスは変わらず（チェック1回のみ）
NumberHandling有効時は既に内部メソッドを使用していたため、性能劣化なし
テスト結果：System.Text.Json全体で49,656テスト全てパス（回帰なし）

その他

ソースコード生成モード（AOT対応）ではGetConverter()が利用できないため、該当テストは適切にスキップされます
.NET Frameworkと.NET Core/.NET両方で動作確認済み
公開API（Read/Writeメソッド）の変更ですが、既存コードとの互換性は完全に維持されます（より厳密になるだけ）

#120688 [clr-interp] Interpreter for ARM32 SOFTFP

作成者: @clamp03
作成日時: 2025年10月14日 06:50:45(UTC)
マージ日時: 2026年01月23日 16:20:59(UTC)
ラベル: area-VM-coreclr community-contribution area-CodeGen-Interpreter-coreclr

概要

ARM32 SOFTFP向けのインタープリータ実装を有効化するPRです。引数と戻り値のアセンブリ実装を追加し、ARM32 SOFTFP呼び出し規約に対応した小さなバグ修正を含みます。簡単なテストケースで検証済みです。

変更内容

アセンブリ実装: ARM32向けアセンブリヘルパー (asmhelpers.S) とアセンブリ定数 (asmconstants.h) を新規追加（427行、31行）
呼び出し規約対応: callstubgenerator.cpp でARM32 SOFTFP向けのスタブ生成ロジック追加（277行追加）
インタープリータ実行: interpexec.cpp/h で引数・戻り値ハンドリングを改善（100行、40行）
メモリ管理: minipal に mprotect 相当機能を追加（Windows/Unix両対応、42行追加）
機能制御: clr.featuredefines.props と clrfeatures.cmake でARM32インタープリータ機能を有効化
アセンブリマクロ: unixasmmacrosarm.inc にARM32向けマクロ追加（22行）

パフォーマンスへの影響

直接的なパフォーマンス測定値は提供されていません。インタープリータは実行速度よりも互換性と柔軟性を優先するため、JITコンパイルと比べて実行速度は低下します。ARM32 SOFTFP環境でのインタープリータ利用が可能になることで、デバッグやコード生成が困難な環境での実行オプションが増えます。

その他

多くのレビュアー（jkotas、janvorli、am11など）による詳細なレビュープロセスを経ており、ARM32特有の呼び出し規約に関する慎重な検討が行われた可能性が高い
SOFTFP（Software Floating Point）呼び出し規約への対応により、FPUを持たないARM32デバイスでの動作を想定している
テストは簡単なケースに限定されているため、本格的な検証は追加のテストプロセスが必要な可能性あり

注意点

目次

カテゴリ別PR一覧

ラベル別PR一覧

#123543 Remove System.ServiceModel.Primitives dependency

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123541 Mark new userevents tests as native AOT incompatible

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123539 Run OneLocBuild and SourceIndex on schedule instead of every commit in runtime-official.yml

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123536 SPMI: Tolerate missing getContinuationType calls

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123535 Avoid C4319 build warnings in libunwind (#122179)

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123530 Disable StringBuilder marshalling tests on native AOT

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123528 Update native AOT ActiveIssue on NegotiateAuthenticationTests

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123525 Remove unused code from CoreCLR utilcode

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123522 [Wasm RyuJit] Fix emission of block and label instructions

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123520 [release/10.0] Fix regression caused by special marker type optimization (#123413)

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123519 [clr-interp] Handle unmanaged thiscall on Windows Arm64

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123513 [clr-interp] Fix jmp instruction to tolerate the call.tail opcode failing to actually tail call

概要

変更内容

パフォーマンスへの影響

関連Issue

その他

#123505 Add package readmes to illink NuGet packages stating SDK-only support

概要

変更内容

パフォーマンスへの影響