注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
- #123637 Use IndexOfAny in BaseConfigurationRecord
- #123636 Skip crypto tests requiring elevation when not elevated
- #123631 [Wasm RyuJit] proper fix for register homing
- #123626 Add documentation links for ByRef fields and byref-like generics
- #123610 Vectorize BitIncrement and BitDecrement for float/double in TensorPrimitives
- #123526 Fix up hijacking on arm32 (preserve async continuation register)
- #123511 Object Writer V1 Demo Features
- #123452 Fix failures in internal validation pipeline
- #123417 Fix STJ source generator for partial class contexts with JsonSerializable attributes on multiple declarations
- #123378 Add allocMem support for allocating multiple data chunks
- #123111 Fix Thread pool priority alternation
- #122959 Port alternation switch optimization from source generator to RegexCompiler
#123637 Use IndexOfAny in BaseConfigurationRecord
- 作成者: @stephentoub
- 作成日時: 2026年01月26日 19:30:09(UTC)
- マージ日時: 2026年01月27日 02:08:40(UTC)
- ラベル: area-System.Configuration
概要
BaseConfigurationRecord.NormalizeConfigSourceメソッド内の文字列検索処理を最適化しました。2つの個別のIndexOf呼び出しを、単一のIndexOfAny呼び出しに置き換えることで、パス区切り文字（\または/）の検出を効率化しています。
// 変更前
int index1 = configSource.IndexOf('\\');
int index2 = configSource.IndexOf('/');
// 変更後
int index = configSource.AsSpan().IndexOfAny('\\', '/');
変更内容
- ファイル:
src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/BaseConfigurationRecord.cs - 変更内容:
- パス区切り文字検索ロジックを2つの
IndexOf呼び出しから1つのIndexOfAny呼び出しに統合 - Span API使用による最適化
- .NET Core 2.1+ API利用可能性に関する古いコメントを削除
- パス区切り文字検索ロジックを2つの
パフォーマンスへの影響
改善あり
IndexOfAnyは複数の文字を同時に検索するため、単一パスで両方の区切り文字を検出できます- 従来の2つの
IndexOf呼び出しと比較して、文字列スキャン回数が削減されます - Span版
IndexOfAnyは、SIMD命令の活用により、特に長い文字列において顕著な高速化が期待できます
関連Issue
なし
その他
- 非破壊的変更（内部実装最適化のみ）
- API署名の変更なし
- 既存の動作は保持されます
- このような細粒度の最適化は、.NET Core 2.1以降で一般的に利用可能なSpan APIを活用する現代的なコーディングパターンの採用を示しています
#123636 Skip crypto tests requiring elevation when not elevated
- 作成者: @stephentoub
- 作成日時: 2026年01月26日 19:05:38(UTC)
- マージ日時: 2026年01月27日 16:49:52(UTC)
- ラベル: area-System.Security
概要
Windows環境で管理者権限なしで実行される場合、X509 PKCS#12ローダーテストの一部をスキップするように修正しました。機械キーストア操作が必要なテストケースが権限不足で失敗するのを防ぎます。
変更内容
ファイル: src/libraries/Common/tests/System/Security/Cryptography/X509Certificates/X509CertificateLoaderPkcs12Tests.WindowsAttributes.cs
[Theory]を[ConditionalTheory]に変更（4つのテストメソッド）Microsoft.DotNet.XUnitExtensionsの using追加PlatformDetection.IsPrivilegedProcessによる権限チェック導入- 権限不足時に
SkipTestException("Test requires administrator privileges.")をスロー - 対象テスト：
VerifyPreserveKeyName（機械キー派のみスキップ）VerifyPreserveAlias（機械キー派のみスキップ）VerifyPreserveProvider（機械キー派のみスキップ）VerifyNamesWithDuplicateAttributes（全体スキップ）
// 例：権限チェック後のスキップ実装
if (useKeyName && !PlatformDetection.IsPrivilegedProcess)
{
throw new SkipTestException("Test requires administrator privileges.");
}
パフォーマンスへの影響
影響なし（テスト実行の条件分岐のみ）
関連Issue
#123632 - Windows非管理者環境でのテスト失敗を修正
その他
なし
#123631 [Wasm RyuJit] proper fix for register homing
- 作成者: @AndyAyersMS
- 作成日時: 2026年01月26日 16:37:44(UTC)
- マージ日時: 2026年01月27日 17:41:30(UTC)
- ラベル: area-CodeGen-coreclr
概要
Wasm RyuJitのレジスタホーミング処理を改善したPRです。フレームポインタレジスタの割り当てを、ローカル変数のスタック格納時に動的に割り当てる方式から、候補識別フェーズで事前割り当てする方式に変更しました。これにより、レジスタが必要な時点で確実に利用可能になります。
変更内容
- registeropswasm.cpp:
WasmRegToIndex関数に検証ロジックを追加し、無効なレジスタ型（Invalid）が渡されないようアサーション処理を実装 - regallocwasm.cpp: フレームポインタレジスタ割り当てを
AllocateAndResolveNodeからIdentifyCandidatesへ移動。ローカル変数が参照を持つ場合、事前にレジスタを割り当て - codegenwasm.cpp:
genHomeRegisterParams内の不要な早期リターンチェック（REG_NAスタックポインタ判定）を削除
パフォーマンスへの影響
影響なし。本変更は登録割り当てパイプラインの構造改善であり、最適化の段階を前倒しするものです。パフォーマンス指標の変化は予想されません。ただし、より堅牢なレジスタ管理により、Wasm環境でのコード生成の信頼性が向上します。
関連Issue
PR #123569と関連。本PRはそのフォローアップ修正です。
その他
- 変更は最小限（計24行の追加削除）で、既存の回帰リスクは低い
- Wasmコンパイル特有の最適化であり、他のターゲット（x86/ARM）への影響なし
- レジスタ割り当てタイミングを事前フェーズに統一することで、コード生成ロジックの複雑性が低減
#123626 Add documentation links for ByRef fields and byref-like generics
- 作成者: @Copilot
- 作成日時: 2026年01月26日 15:42:26(UTC)
- マージ日時: 2026年01月27日 18:47:13(UTC)
- ラベル: 指定なし
概要
ByRef フィールドと byref-like ジェネリクス機能に関するドキュメントに参照リンクを追加し、説明の明確化と具体例の追加を行いました。C# 言語仕様への提案リンク、roslyn issue への参照、および実装済み機能の具体的な使用例を文書に統合し、機能の現在の状態を明確に示しています。
変更内容
docs/design/specs/Ecma-335-Augments.md
- "Ref Fields" セクションに sunset restricted types proposal と dotnet/roslyn#64811 へのリンクを追加
- ByRef フィールド一般化の必要性に関する説明を 2 つの段落に分割し、リンク順序を明確化
- "ByRefLike types in generics" セクションにも同様のリンクを追加
docs/design/features/byreflike-generics.md
- 実装済み機能の具体例を追加
Action<Span<char>>とFunc<int, Span<byte>>のデリゲートベース API 例string.Create<TState>(int length, TState state, SpanAction<char, TState> action)で効率的な文字列作成例を追加
Span<TypedReference>とSpan<Span<char>>が将来の追加候補であることを明確化
- 実装済み機能の具体例を追加
パフォーマンスへの影響
影響なし
関連Issue
- dotnet/roslyn#64811（ByRef フィールドの一般化に関連）
その他
なし
#123610 Vectorize BitIncrement and BitDecrement for float/double in TensorPrimitives
- 作成者: @Copilot
- 作成日時: 2026年01月26日 02:16:09(UTC)
- マージ日時: 2026年01月27日 12:22:08(UTC)
- ラベル: area-System.Numerics.Tensors
概要
TensorPrimitivesのBitIncrementとBitDecrement操作をfloatおよびdouble型向けにSIMD対応させました。ブランチフリーの実装により、ConditionalSelectを最小限（2回）に抑えた効率的なベクトル化を実現しています。特殊値（NaN、±Infinity、±0.0）の処理をビット演算で統合し、コード行数を56%削減しました。
// BitIncrement: float型の例
Vector128<float> xFloat = x.AsSingle();
Vector128<uint> bits = xFloat.AsUInt32();
Vector128<uint> isNegative = Vector128.Equals(bits & Vector128.Create(0x8000_0000u), Vector128.Create(0x8000_0000u));
Vector128<uint> result = Vector128.ConditionalSelect(isNegative, bits - Vector128<uint>.One, bits + Vector128<uint>.One);
変更内容
TensorPrimitives.BitIncrement.cs / BitDecrement.cs
Vectorizableをfloat/double型でのみtrueに変更- Vector128/256/512向けのSIMD実装を追加
- ビット演算による符号判定と加減算の実装
- 特殊値処理：NaN→NaN、-0.0→Epsilon（BitIncrement）、+0.0→-Epsilon（BitDecrement）
- -Infinity→MinValue、+Infinity→MaxValue等の処理を統合
パフォーマンスへの影響
大幅な改善を実現：
| 型 | 改善前 | 改善後 | 改善率 |
|---|---|---|---|
| float | 848.3 ns | 227.8 ns | 3.7倍高速化 |
| double | 1,691.5 ns | 445.4 ns | 3.8倍高速化 |
ブランチフリー設計によるパイプライン効率の向上とベクトル化による並列処理が改善の主因です。Half型は38%のパフォーマンス低下が確認されたため、スカラーフォールバックを使用します。
関連Issue
なし
その他
- コード品質：ベクトルコードが56%削減（192→84行）
- Half型対応は検討されましたが、パフォーマンス低下が顕著なため非対応
- すべてのビルド、テスト、セキュリティスキャンが成功
#123526 Fix up hijacking on arm32 (preserve async continuation register)
- 作成者: @eduardo-vp
- 作成日時: 2026年01月23日 04:47:46(UTC)
- マージ日時: 2026年01月27日 08:28:32(UTC)
- ラベル: area-NativeAOT-coreclr runtime-async
概要
ARM32でのGCヒジャッキング時に、非同期継続レジスタ（r2）を正しく保持するようにする修正です。従来はr0とr1のみを保存していましたが、ARM32の非同期呼び出し規約ではr2が継続値を返すため、GC中にr2が失われるとコードの不正な動作につながります。フラグ定義を追加し、プローブフレームでr0-r2を保存・復元するように修正しました。
変更内容
src/coreclr/nativeaot/Runtime/unix/unixasmmacrosarm.inc
PTFF_SAVE_R1とPTFF_SAVE_R2フラグ定義を追加（PInvokeTransitionFrameFlags列挙型に対応）src/coreclr/nativeaot/Runtime/arm/GcProbe.S
PUSH_PROBE_FRAME、POP_PROBE_FRAME、FixupHijackedCallstackマクロを更新し、r0-r2の保存・復元に対応- GCプローブフレームサイズを88バイトから96バイトに変更（8バイトアライメント対応）
RhpGcProbeHijackで新フラグを設定
パフォーマンスへの影響
スタックフレームサイズが8バイト増加（88→96バイト）しますが、これはGC停止時の短期的なメモリ使用量増加であり、実行時性能への大きな影響は想定されません。ただしスタック負荷が高い環境では若干の影響がある可能性があります。
関連Issue
なし
その他
- 本修正は先行PR #123057の失敗に対応するものです（#123057はouterloopruns でクラッシュが発生したため#123474で一度リバートされた）
- ARM32のCLR ABI仕様に準拠した修正であり、非同期操作の信頼性向上に重要です
#123511 Object Writer V1 Demo Features
- 作成者: @adamperlin
- 作成日時: 2026年01月22日 21:36:12(UTC)
- マージ日時: 2026年01月27日 22:17:39(UTC)
- ラベル: arch-wasm area-crossgen2-coreclr
概要
このPRは、crossgen2のWebAssemblyオブジェクトライターにテスト用WASMモジュール生成に必要な機能を追加します。具体的には、ランタイムスタック用のデータセクションオフセット（0x10000/64KB）、テーブルセクション、そして.NETメソッドシグネチャからWASM型シグネチャへの変換ロジックを実装しています。
// WASM型シグネチャ生成の例
// .NET型 -> WASM型への対応付け
public void GenerateTypeSignature(MethodDesc method)
{
// メソッドのパラメータと戻り値を WASM value types に変換
}
変更内容
WasmObjectWriter.cs (+162/-31)
- データセクションオフセット: 0x10000（64KB）の予約領域をランタイムスタック用に確保
- テーブルセクション: メソッド数に基づいて設定可能なサイズのWASMテーブルセクションを追加
- エクスポート機能の拡張: 関数、テーブル、メモリ、グローバル変数など複数のエクスポートタイプに対応
- 型シグネチャ生成: .NETメソッドシグネチャをWebAssembly型シグネチャに変換するロジックを実装
パフォーマンスへの影響
影響なし。本変更はメタデータ生成と構造化に関するもので、ランタイム実行性能には直接的な影響はありません。
関連Issue
なし
その他
このPRはwasm-ryujit-runnerテストハーネスで使用可能なWASMモジュール生成を目的としており、crossgen2がWebAssemblyコンパイルターゲットに対応するための基盤を整備しています。
#123452 Fix failures in internal validation pipeline
- 作成者: @jkoritzinsky
- 作成日時: 2026年01月21日 23:13:16(UTC)
- マージ日時: 2026年01月27日 23:05:57(UTC)
- ラベル: needs-area-label
概要
内部検証パイプラインの障害を修正するPRです。Helixキューの構成調整とプライベートNuGetフィード認証のサポート追加により、クロスプラットフォームビルドの信頼性を向上させます。主な変更としてAndroidキュー選択ロジックをUbuntuベースに統一し、iOS/tvOS/Android/Browser WASMプラットフォームでパブリック/インターナルキューの区別を実装しています。
変更内容
- eng/pipelines/libraries/helix-queues-setup.yml (+4/-2): Android内部ビルドのキュー選択をUbuntu.2204に統一
- eng/pipelines/coreclr/templates/helix-queues-setup.yml (+28/-7): パブリック/インターナルビルドに応じてHelixキュー選択を条件付けする処理を追加（複数プラットフォーム対応）
- eng/pipelines/common/templates/runtimes/xplat-job.yml (+2/-0): 非公開ビルド時のプライベートNuGetフィード認証設定ステップを追加
- その他ファイル: グローバルビルドジョブ、診断パイプライン、テスト実行ジョブのクリーンアップ（合計 -63/+39の変更）
パフォーマンスへの影響
影響なし（パイプライン設定の修正であり、ランタイムやコンパイラの動作には直接影響しません）
関連Issue
- dotnet/runtime#123444（このPRで修正）
その他
本変更はCI/CDパイプラインの信頼性向上に焦点を当てています。Windowsベースキューの利用不可時にUbuntuベースキューにフォールバックする仕組みにより、プラットフォーム固有の環境問題を回避します。プライベートフィード認証の追加は、内部ビルドで機密パッケージへのアクセス要件に対応しています。
#123417 Fix STJ source generator for partial class contexts with JsonSerializable attributes on multiple declarations
- 作成者: @Copilot
- 作成日時: 2026年01月21日 04:06:25(UTC)
- マージ日時: 2026年01月27日 01:39:46(UTC)
- ラベル: area-System.Text.Json
概要
STJ（System.Text.Json）のソースジェネレーターが、複数の部分的なクラス宣言に分割されたJsonSerializerContextで各宣言に[JsonSerializable]属性がある場合に失敗する問題を修正します。根本原因は、ForAttributeWithMetadataNameが各部分宣言ごとにトリガーされる一方、GetAttributes()がすべての部分宣言の属性を返すため、同じ名前のコード生成が重複することでした。
// ファイル1.cs
[JsonSerializable(typeof(MyClass1))]
internal partial class SerializerContext : JsonSerializerContext { }
// ファイル2.cs
[JsonSerializable(typeof(MyClass2))]
internal partial class SerializerContext { }
変更内容
- JsonSourceGenerator.Parser.cs:
IsCanonicalPartialDeclaration()メソッドを追加し、ファイルパスのアルファベット順で最初の部分宣言を正規部分として選択。このチェックをParseContextGenerationSpec()前に統合し、非正規部分はnullを返すように変更 - JsonSourceGeneratorTests.cs:
PartialContextClassWithAttributesOnMultipleDeclarationsユニットテストを追加。複数宣言にまたがる属性を正しく処理することを検証 - PartialContextTests.Part1.cs / Part2.cs: ランタイムテスト用の個別の部分宣言ファイルを作成
- JsonSerializerContextTests.cs:
PartialContextWithAttributesOnMultipleDeclarations_RuntimeBehaviorテストを追加。両方の部分宣言からの型のシリアライゼーション/デシリアライゼーションが正しく動作することを検証
パフォーマンスへの影響
影響なし。本修正は、正規部分の判定（ファイルパスのアルファベット順）を追加するのみで、パフォーマンスへの悪影響はありません。むしろ、重複コード生成による失敗を防ぐため、全体的な安定性が向上します。
関連Issue
dotnet/runtime#99669（STJのソースジェネレーターが複数の部分クラスで失敗する）
その他
.NET 7では動作していましたが、PR #86616でIDEパフォーマンス向上のため各部分宣言を独立処理するように変更された際に、この回帰が発生しました。本修正により、メタデータから生成された部分クラスと開発者が追加する部分クラスを組み合わせて使用できるようになり、利便性が向上します。
#123378 Add allocMem support for allocating multiple data chunks
- 作成者: @jakobbotsch
- 作成日時: 2026年01月20日 13:36:36(UTC)
- マージ日時: 2026年01月27日 12:53:22(UTC)
- ラベル: area-CodeGen-coreclr
概要
allocMem APIを再設計し、固定的なホット/コールド/読み取り専用データブロックから、任意数のデータチャンクを割り当てられる柔軟な構造へ変更しました。これにより ILC がテキストセクションへのリロケーション対応セクションに非同期再開情報チャンクを配置可能になり、複数関数間での読み取り専用データ共有もサポートします。
// 変更前: 固定フィールド
struct AllocMemArgs {
void* hotCodeBlock;
void* coldCodeBlock;
void* roDataBlock;
};
// 変更後: 柔軟なチャンク配列
struct AllocMemChunk {
void* ptr;
size_t size;
CorJitAllocMemFlag flags; // HOT_CODE, COLD_CODE, READONLY_DATA, HAS_POINTERS_TO_CODE
};
変更内容
- 公開API変更:
corjit.hのAllocMemArgs構造体を廃止し、AllocMemChunk配列ベースの設計に刷新 - フラグシステム簡素化:
CorJitAllocMemFlagをアラインメント固有フラグからチャンクタイプフラグ（HOT_CODE、COLD_CODE、READONLY_DATA、HAS_POINTERS_TO_CODE）に変更 - AllocCode API変更: アラインメントをフラグから導出する代わりにパラメータとして受け取るよう変更（src/coreclr/vm/codeman.h/.cpp）
- JIT実装更新: emit.h/.cpp で
emitDataChunks、emitDataChunkOffsets、バイナリサーチ用emitDataOffsetToPtrを追加、複数データオフセット対応 - VM層対応: jitinterface.cpp の CEEJitInfo/CInterpreterJitInfo がチャンク配列を処理
- ツール更新: SuperPMI、crossgen2、インタプリタが新しい構造に対応
- JIT/EE版GUID更新: 互換性のため jiteeversionguid.h を更新
パフォーマンスへの影響
改善点:
- 複数関数間で読み取り専用データを共有可能になり、メモリ効率向上
emitDataOffsetToPtrバイナリサーチ導入により、複数データチャンク環境での検索パフォーマンス向上
懸念点:
- チャンク配列処理に伴う初期オーバーヘッド（ただし ArrayStack ベースで限定的）
- アラインメント計算のロジック複雑化の可能性
関連Issue
なし
その他
- 破壊的変更: JIT/EE インターフェース版GUID更新により、新旧ランタイムの互換性なし
- スコープ: 26ファイル変更、内部実装層（JIT、VM、ツール）に集中した変更で、公開API への直接影響は限定的
- アーキテクチャ対応: x86/ARM/RISC-V/LoongArch64 すべての emit バックエンドで統一的に対応
#123111 Fix Thread pool priority alternation
- 作成者: @eduardo-vp
- 作成日時: 2026年01月13日 00:58:51(UTC)
- マージ日時: 2026年01月27日 01:18:49(UTC)
- ラベル: area-System.Threading
概要
スレッドプールの優先度交替メカニズムのバグを修正しました。_dispatchNormalPriorityWorkFirstフラグの切り替えが条件付きブロック内でのみ実行されていたため、優先度の適切な交替が行われず、通常優先度の作業アイテムが飢餓状態に陥る可能性がありました。フラグの切り替えを条件付きブロックの外に移動し、DequeueWithPriorityAlternationの呼び出しごとに確実に実行されるようにしました。
変更内容
- src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs
_dispatchNormalPriorityWorkFirstフラグの切り替えロジックを修正- フラグの切り替えを条件付きブロックの外に移動し、毎回のデキュー試行時に実行されるように変更
パフォーマンスへの影響
改善点：通常優先度の作業アイテムの飢餓状態が解消され、スレッドプール内での優先度交替が正常に動作するようになります。これにより、高優先度と通常優先度の作業がより公平に処理され、全体的なスループット安定性が向上します。
関連Issue
#123111
その他
- 修正内容はシンプルであり、フラグ切り替えのタイミングに関する内部実装の改善です
- 公開APIの変更はなく、内部動作の修正のため互換性への影響はありません
- 削除行が多い（-28）ため、コンディショナルロジックの簡潔化も含まれている可能性があります
#122959 Port alternation switch optimization from source generator to RegexCompiler
- 作成者: @Copilot
- 作成日時: 2026年01月07日 03:18:19(UTC)
- マージ日時: 2026年01月27日 02:19:53(UTC)
- ラベル: area-System.Text.RegularExpressions
概要
正規表現コンパイラに、ソースジェネレータから交互分岐最適化をポートしました。各分岐が異なる文字で始まる交互分岐に対して、C#スイッチ文をILレベルで発行する最適化です。Roslyn の휴리스틱（要素数 >= 7 かつ密度 >= 0.5）を使用して、パフォーマンスが向上する場合にのみ適用されます。
// 最適化前: 複数のif-elseで分岐
// 最適化後: IL switch で高速な分岐
if (input[pos] == 'a') { /* branch A */ }
else if (input[pos] == 'b') { /* branch B */ }
else if (input[pos] == 'c') { /* branch C */ }
// ... IL switch で効率的に実装
変更内容
- RegexCompiler.cs:
TryEmitAlternationAsSwitchとEmitSwitchedBranchesメソッドを追加し、IL レベルでの switch 最適化を実装 - RegexNode.cs:
TryGetAlternationStartingCharsメソッドを追加し、交互分岐の開始文字取得ロジックを共有化 - RegexGenerator.Emitter.cs: 既存の C# レベルのswitch 最適化ロジックを簡潔にリファクタリング
- Regex.Match.Tests.cs: 新しい最適化パスの機能テストを追加
パフォーマンスへの影響
交互分岐で複数の条件分岐がある場合、IL switch による O(1) ジャンプにより、if-else チェーンの O(n) 相比で大幅に高速化します。Roslyn の密度ヒューリスティック（count/range >= 0.5、count >= 7）により、最適化が有益な場合のみ適用され、テーブルサイズが無駄に増加する懸念を軽減します。
関連Issue
なし
その他
- ソースジェネレータと RegexCompiler の実装同期を進める作業の一環です
- 既存の全機能テストが合格することが要件です
- 新規テストの追加は不要（既存テストカバレッジで十分）