Pull Request on 2026年03月07日

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

注意点

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

#125286 Fix GetModule_ReturnsModule test failure on browser-wasm

  • 作成者: @lewing
  • 作成日時: 2026年03月07日 00:05:26(UTC)
  • マージ日時: 2026年03月07日 21:12:20(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

browser-wasm環境でのテスト失敗を修正するPRです。PR #125080で追加されたelse分岐が!HasAssemblyFilesをNativeAOTのみの条件と想定していましたが、browser-wasmもAssembly.Locationが空のため同じ条件を満たすことが原因でした。NativeAOTとwasm環境を別々に処理するよう条件分岐を分割し、各環境の異なるModule.Nameの挙動に対応させています。

変更内容

  • ファイル: src/libraries/System.Reflection.Context/tests/ExtendedAssemblyTests2.cs
    • NativeAOT環境: Module.Name == "<Unknown>"をアサート
    • wasm/その他環境: GetModule(moduleName)を呼び出しnull以外をアサート
    • 変更行数: +3/-12（テスト条件の分岐処理を追加・整理）

パフォーマンスへの影響

影響なし

関連Issue

  • Fixes #125245
  • References #125080（修正対象となった元のPR）

その他

Module.Nameの戻り値は環境により異なります：

  • NativeAOT: "<Unknown>"（アセンブリファイルが存在しないため）
  • wasm (Mono): 実際のDLL名（例: "System.Reflection.Context.Tests.dll"）
  • browser-wasm環境ではAssembly.Locationが空文字列となるにもかかわらず、Monoランタイムは実DLL名を返すため、環境別の処理分岐が必要でした。

#125285 Revert "Eliminate forwarder stubs by reusing method precodes for call counting indirection"

  • 作成者: @agocke
  • 作成日時: 2026年03月07日 00:00:57(UTC)
  • マージ日時: 2026年03月07日 04:46:53(UTC)
  • ラベル: area-VM-coreclr

概要

PR #124664で導入された最適化がNuGetリストア性能で12-13%の回帰を引き起こしたため、この変更を元に戻すリバートです。問題はThePreStub内のRtlEnterCriticalSectionで過度な時間が消費されていたことが原因です。この変更により、仮エントリーポイントの再利用からコール計数用の専用フォワーダースタブへ戻すことで、パフォーマンスを回復させます。

変更内容

  • src/coreclr/vm/callcounting.cpp: フォワーダースタブの割り当て/利用ロジックを再導入し、ハッシュテーブルのリセット/削除/トリミングロジックを追加
  • src/coreclr/vm/callcounting.h: バックパッチ可能メソッド向けフォワーダープリコードに関する設計コメントを更新し、フォワーダースタブハッシュメンバー/トレイトを追加
  • src/coreclr/vm/method.cpp: MethodDesc::TryBackpatchEntryPointSlotsにFORCEINLINEアノテーションを追加
  • src/coreclr/vm/prestub.cpp: vtableスロットバックパッチ対象メソッドの不変条件説明を簡略化

パフォーマンスへの影響

改善: NuGetリストアパフォーマンスで12-13%の性能低下を解決。ThePreStub内のRtlEnterCriticalSectionでの時間消費が削減されます。

バックパッチ可能メソッド（仮想/インターフェースメソッド）に対して専用フォワーダースタブを使用することで、仮エントリーポイント再利用時の同期オーバーヘッドを軽減します。

関連Issue

なし

その他

本リバートはJIT呼び出し計数機構の設計に関する重要な変更です。仮エントリーポイントの再利用による最適化とメモリ効率性（フォワーダースタブ削減）のトレードオフが、実運用性能ではパフォーマンスが優先されることを示しています。

#125282 Fix interpreter async suspend DiagnosticIP calculation

  • 作成者: @davidwrighton
  • 作成日時: 2026年03月06日 21:54:50(UTC)
  • マージ日時: 2026年03月07日 01:21:04(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

インタープリタの非同期サスペンド処理において、DiagnosticIPが絶対アドレスとして保存されていた問題を修正しました。DiagnosticIPはオフセット値として保存し、FinalizeMethodData時に最終的なバイトコードベースアドレスを加算することで、他のフィールド（methodStartIPなど）と同じ方式に統一しました。これにより、Apple mobileでのAsync例外処理テストにおけるクラッシュが解決されます。

変更内容

  • src/coreclr/interpreter/compiler.cpp: INTOP_HANDLE_CONTINUATION_SUSPENDでDiagnosticIPをメソッドコード開始からのオフセットとして保存し、ファイナライズ時にバイトコードベースアドレスを加算
  • src/tests/async/simple-eh/simple-eh.cs: このバグにより無効化されていた3つのテストのActiveIssue属性を削除

パフォーマンスへの影響

影響なし。本修正はバグ修正であり、リロケーション処理の手順を正規化するもので、パフォーマンスに関連した変更ではありません。

関連Issue

#124044（インタープリタ非同期サスペンド時のToString_Asyncおよびその他非同期例外処理テストのクラッシュ）

その他

本修正はApple mobileプラットフォームでのCoreCLR R2Rおよびインタープリタフォールバック環境における問題の解決に該当します。DiagnosticIPのオフセットベースのリロケーション方式は既存の他のフィールド（methodStartIPなど）と一貫性を持つようになります。

#125280 Fix BOL anchor not writing back updated position in TryFindNextPossibleStartingPosition

  • 作成者: @Copilot
  • 作成日時: 2026年03月06日 21:41:37(UTC)
  • マージ日時: 2026年03月07日 01:24:57(UTC)
  • ラベル: area-System.Text.RegularExpressions

概要

正規表現の行頭アンカー（^ with Multiline）処理で、ベクトル化されたIndexOf('\n')により計算された位置がバッファに書き戻されていない不具合を修正しました。修正により、マルチラインパターンでのパフォーマンスが最大595倍向上しています。

変更内容

  • RegexCompiler.cs: IL コンパイラ側で BOL 最適化後に計算された pos を base.runtextpos フィールドへ永続化する処理を追加
  • RegexGenerator.Emitter.cs: ソースジェネレータ側で BOL による位置進行後に base.runtextpos = pos; を生成するコードを追加

パフォーマンスへの影響

大幅な改善 - ベンチマーク結果より：

Linux AMD64（EPYC 9V45）:

  • 5文字間隔: 2.3倍高速化（32.51μs → 13.97μs）
  • 80文字間隔: 31倍高速化（447.66μs → 14.22μs）
  • 320文字間隔: 108倍高速化（1,763.62μs → 16.40μs）
  • 1280文字間隔: 333倍高速化（11,002.82μs → 33.08μs）

macOS ARM64（Apple M4）:

  • 1280文字間隔: 595倍高速化（36,555.42μs → 61.44μs）

修正前は計算されたIndexOfの結果が破棄されていたため、文字単位のスキャンが繰り返されていました。修正後は間隔サイズに比例した線形の高速化が確認されています。

関連Issue

#125280

その他

全機能テスト（30,817件）とユニットテスト（1,034件）がパス済み。BOL が唯一の最適化パスとなるベアな^パターンで特に顕著な改善効果があります。

#125259 Replace MemoryBarrier with Volatile operations in HashMap

  • 作成者: @AaronRobinsonMSFT
  • 作成日時: 2026年03月06日 07:52:03(UTC)
  • マージ日時: 2026年03月07日 05:41:53(UTC)
  • ラベル: area-VM-coreclr

概要

dotnet/runtimeのHashMap実装（hash.cpp）において、フルメモリバリア（MemoryBarrier()）を、より効率的なボラタイル操作（VolatileLoad/VolatileStore）に置き換えました。フルフェンス（ARM64のdmb ish、x86のmfence）は単方向の順序付けが必要な場合に過度にコストがかかるため、release/acquireセマンティクスを使い分けることで、キャッシュコヒーレンシを損なわずにパフォーマンスを改善します。

変更内容

  • src/coreclr/vm/hash.cpp (+29/-35)
    • InsertValue: キー公開時にVolatileStore（release）を使用し、値がキーより前に可視化
    • LookupValue/ReplaceValue/DeleteValue: キーマッチ時にVolatileLoad（acquire）を使用し、後続の値読み取りを順序付け
    • ReplaceValue: 新値をプレーンストア後、キーを再公開時にVolatileStore（release）を使用
    • Rehash: m_rgBucketsポインタ公開時にVolatileStore（release）を使用。読者側はEBR臨界領域エントリ時のフルメモリバリアにより同期

パフォーマンスへの影響

改善あり

ARM64での命令削減：

  • InsertValue: dmb ish + str → stlr（1命令削減）
  • キーマッチ読み取り: dmb ish → ldar（フェンス命令を軽量ロードに置換）
  • ReplaceValue: str + dmb ish → str + stlr
  • Rehashポインタ公開: dmb ish + str → stlr

x86/x64ではVolatileLoad/VolatileStoreがコンパイラフェンスのみ（TSO提供のハードウェア順序付けを活用）となり、mfenceの発行を削減可能。

関連Issue

なし

その他

重要な設計ポイント：

  • Release-acquireペアが同一アドレスで形成され、古い値または完全に更新された新値のいずれかを観測することを保証
  • EBR（Epoch-Based Reclamation）臨界領域との同期により、Rehash時の可視化を確保
  • これは内部実装の最適化であり、公開APIへの互換性影響なし

#125254 Implement ValueAsnReader

  • 作成者: @vcsjones
  • 作成日時: 2026年03月06日 03:20:42(UTC)
  • マージ日時: 2026年03月07日 02:10:33(UTC)
  • ラベル: area-System.Security

概要

ValueAsnReaderという新しい公開API をSystem.Formats.Asn1パッケージに実装し、既存の内部用AsnValueReaderを段階的に置き換えています。このPRは2つのコミットで構成されており、新しいAPIの実装・テストと、既存のASN関連の自動生成ファイルの更新を行っています。完全な置き換えは今後のフォローアップPRで実施予定です。

// 新しいValueAsnReaderの使用例（推定）
ValueAsnReader reader = new ValueAsnReader(data, AsnEncodingRules.DER);
// 既存のAsnValueReaderから移行

変更内容

  • System.Formats.Asn1パッケージ: 新しい公開APIValueAsnReaderを実装
  • 自動生成ファイル（173ファイル）: asn.xsltの更新に伴い、ASN1関連の自動生成ファイルを更新
    • AlgorithmIdentifierAsn, AttributeAsn, CurveAsn, DigestInfoAsn等の暗号化関連ASN.1型定義ファイルのAPI呼び出しを新しいAPIに置き換え
  • Common/src/Internal/Cryptography: PkcsHelpers.csなど既存の実装をアップデート

パフォーマンスへの影響

影響なし

このPRは主にAPIの新規実装と段階的な置き換えであり、パフォーマンス改善や劣化は想定されていません。

関連Issue

#109019（新しいValueAsnReader公開APIの実装要件）

その他

  • このPRは段階的な置き換えのフェーズ1です。内部用AsnValueReaderの完全削除はフォローアップPRで実施予定
  • 2つのコミットに分割されており、必要に応じて2つの個別PRに分割することも可能
  • 新しいAPIの機能性を他のユニットテストで検証するため、実際の使用例を含めています

#124940 Implement cDAC API GetCCWInterfaces

  • 作成者: @Copilot
  • 作成日時: 2026年02月27日 03:23:21(UTC)
  • マージ日時: 2026年03月07日 05:03:18(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

cDAC（Common Data Access API）のGetCCWInterfaces API を実装し、COM Callable Wrapper（CCW）が公開するCOMインターフェースの検査を可能にしました。レガシーDAC実装に依存せず、ランタイムデータディスクリプタから直接CCWチェーン内のインターフェースを列挙できるようになります。

// COM インターフェースポインタから ComCallWrapper を解決
public TargetPointer GetCCWFromInterfacePointer(TargetPointer interfacePointer);

// ComCallWrapper チェーン内の COM インターフェースを列挙
public IEnumerable<COMInterfacePointerData> GetCCWInterfaces(TargetPointer ccw);

変更内容

  • ランタイムデータディスクリプタ: ComMethodTable の新規追加、CCWインターフェースポインタ走査、Tear-off AddRef 識別用のグローバルを追加
  • cDAC契約実装: BuiltInCOM_1.GetCCWInterfaces の実装、COM-IP→CCW解決ロジック
  • データ型拡張: ComCallWrapper、SimpleComCallWrapper、ComMethodTable の新規フィールド追加
  • レガシーSOS橋接: ISOSDacInterface.GetCCWInterfaces を cDAC 契約経由で実装、DacpCOMInterfacePointerData 型の追加
  • テスト追加: ユニットテスト（627行）とWindows限定のダンプベース統合テスト（新規CCWInterfacesデバッギーと検証テスト）
  • ドキュメント: BuiltInCOM設計ドキュメントの更新

パフォーマンスへの影響

影響なし

本変更は診断APIの追加実装であり、ランタイム実行パスのパフォーマンスへの直接的な影響はありません。デバッガやプロファイラが利用するインスペクション機能の拡張です。

関連Issue

なし

その他

  • テストカバレッジ: CCW参照カウント取得（GetRefCount）、弱参照ハンドル判定（IsHandleWeak）、標準CCW/SCCW IPの解決、リンク済みラッパー走査、インターフェース列挙をカバー
  • プラットフォーム制限: ダンプテストは[SkipOnOS(IncludeOnly = "windows")]でWindows限定（GCHandle + Marshal.GetIUnknownForObject 経由でCCW生成）
  • 検証内容: 3つ以上のCCWポインタ検出、各CCWが1つ以上のインターフェースエントリを持つ、MethodTableエントリがIRuntimeTypeSystem.GetTypeHandleで解決可能であることを検証

#124832 Vectorize custom polynomial CRC-32 and CRC-64

  • 作成者: @bartonjs
  • 作成日時: 2026年02月24日 23:08:25(UTC)
  • マージ日時: 2026年03月07日 00:37:54(UTC)
  • ラベル: area-System.IO.Hashing

概要

System.IO.Hashing内のCRC-32およびCRC-64の計算処理をベクトル化することで、パフォーマンスを向上させました。UpdateVectorizedで128ビット単位のデータを処理し、残りをUpdateScalarで処理する2段階アプローチを採用。カスタムポリノミアル対応のテストケースも追加されています。

変更内容

  • CRC計算エンジンの再設計: CrcParameterSetベースクラスを導入し、Vectorized実装（CrcXXParameterSet.Vectorized.cs）とTable実装（CrcXXParameterSet.Table.cs）を統合。UpdateVectorizedメソッドで最大128ビット単位のデータ処理に対応
  • プラットフォーム対応: .NET Frameworkおよびビッグエンディアンシステムではスカラー処理のみ、その他のシステムではベクトル処理を活用
  • ヘルパークラス追加: CrcPolynomialHelper.csを新規追加し、カスタムポリノミアルの定数計算をサポート
  • テストケース拡充: Crc32Tests_ParameterSet_Custom.cs、Crc64Tests_Parameterized_Custom.csでカスタムポリノミアル対応テストを実装
  • 既存実装の整理: プラットフォーム別の専用ファイル（Crc32.Arm.cs、Crc32.Vectorized.csなど）を削除し、ParameterSetクラスに統合

パフォーマンスへの影響

改善: ベクトル化処理により、対応プラットフォーム（x64、ARM）でCRC計算速度が向上。128ビット単位のバルク処理とCRC-32/C（x64・ARM）、CRC-32/IEEE（ARM）などのCPU固有命令活用により実行速度が向上。スカラー処理へのフォールバックにより互換性を損なわない設計。具体的な計測値は提供されていません。

関連Issue

  • #124576（当PR で修正）

その他

本変更は構造的なリファクタリングであり、既存APIに変更なし。カスタムポリノミアルの定数計算が正しく実装されていることを検証するため、新規テストケースが追加されています。プロジェクトファイル（.csproj）の微調整も含まれています。

目次