注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
#132345 Restore Windows Arm64 support for CPUs without LSE
- 作成者: @tannergooding
- 作成日時: 2026年08月14日 22:09:34(UTC)
- マージ日時: 2026年08月15日 16:46:00(UTC)
- ラベル: area-VM-coreclr
概要
Windows Arm64ランタイムにおいて、LSE（Large System Extensions）をオプション機能として扱い、基本CPU要件をArmv8-Aに戻します。これにより、LSEなしのNXP i.MX 8プロセッサを搭載したWindows 10 IoTデバイスでの実行をサポートしながら、ReadyToRunの基準はArmv8.2-A + RCPCのままとします。LSEなしのハードウェアではR2Rイメージが拒否され、JITにフォールバックします。
変更内容
- cpufeatures.c: Windows Arm64でLSEをオプション機能として扱い、存在する場合は機能を報告するが、未実装時はベースライン無効とはしないように修正
- codeman.cpp: CoreCLR起動時のエラーメッセージから、Windows Arm64では必須ではないLSEの要件を削除
- InstructionSetHelpers.cs: NativeAOT向けの非R2R ARM64ビルドから、Windows固有のLSEベースライン要件を削除
- startup.cpp: NativeAOT起動時のエラーメッセージをCoreClrに合わせて更新
パフォーマンスへの影響
影響なし
関連Issue
その他
このPRはGitHub Copilotで作成されました。ReadyToRun基準は変更されないため、既存のR2R契約は保持されます。
#132342 Skip GitHub_130545 on NativeAOT
- 作成者: @agocke
- 作成日時: 2026年08月14日 21:44:02(UTC)
- マージ日時: 2026年08月15日 19:29:19(UTC)
- ラベル: area-TypeSystem-coreclr
概要
NativeAOT環境でGitHub_130545回帰テストがジェネリック制約メタデータの解決時にTypeLoadExceptionで失敗するため、NativeAOT上でのみテストをスキップします。CoreCLRおよびMonoでのテストカバレッジは維持され、基盤となるNativeAOT反射メタデータバグはIssue #132030で追跡継続します。
変更内容
- GitHub_130545.cs:
TestLibrary.Utilities.IsNativeAotによる条件付きスキップを[ActiveIssue]属性で追加 - GitHub_130545.csproj: ランタイム検出を可能にするため、プロジェクト参照に
TestLibraryを追加
パフォーマンスへの影響
影響なし
関連Issue
その他
本変更はNativeAOT環境での一時的な回避策であり、根本的なNativeAOTの反射メタデータ関連の問題解決は別途Issue #132030で追跡されます。
#132302 Add locking for cDAC APIs
- 作成者: @rcj1
- 作成日時: 2026年08月14日 05:02:13(UTC)
- マージ日時: 2026年08月15日 01:14:18(UTC)
- ラベル: area-Diagnostics-cdac
概要
cDAC（Common Data Access）APIs が同じ Target を共有する場合、複数スレッドからの同時アクセスを防ぐため、per-Target の ApiLock を導入しました。COM エントリーポイント全体にMonitorベースのロック機構を実装し、スレッド間の再入性を防ぎます。この変更は内部実装（Legacy COM インターフェース層）に限定され、公開 API への直接的な影響はありません。
変更内容
- Entrypoints.cs:
TargetとApiLockをペアで保管し、作成される SOS/DacDbi インスタンスへ共有ロックを渡す - ComInterfaceLock.cs:
Monitorロックをスコープ化するための軽量 RAII ヘルパー(IDisposable)を追加 - SOSDacImpl.cs 関連:
_apiLockフィールドを追加し、IXCLRDataProcess メソッドおよび ICLRDataEnumMemoryRegions メソッドをロック化。外部通知コールバック実行時はロック解放後に呼び出しを実行し、デッドロック回避 - DacDbi ラッパー群 (ClrDataValue, ClrDataFrame, ClrDataTask, ClrDataModule など): 各 COM メソッドの実装時に
_apiLockでシリアライズ化。返却されるラッパーオブジェクトへロックを伝播 - MetaDataImportImpl.cs: COM メソッドをロック化し、既存の ConcurrentDictionary 使用方法との整合性を改善
- テストファイル: 57 個の単体テスト・ダンプテストを更新し、新しい
apiLockコンストラクタパラメータを供給
パフォーマンスへの影響
各 cDAC API 呼び出しは追加の Monitor.Enter/Exit オーバーヘッドを被ります。ロック保有時間は極力短縮されています（外部コールバック実行時はロックを解放）。大規模な同時アクセスがない診断シナリオでは影響は軽微と予想されますが、ベンチマーク結果は提供されていません。
関連Issue
なし
その他
Copilot の指摘により、以下の潜在的な問題が抽出されています：
Entrypoints.csの既存ハンドルからのインターフェース作成時、ValidateForDataAccess()がロック外で実行され、他の cDAC API との競合リスクが存在MetaDataImportImpl.csの_cdacEnumHandlesConcurrentDictionary のコメントは、現在はロック保護されているため更新が必要
本変更は共有 Target へのシリアルアクセスを保証しますが、レビュー時に指摘された競合条件（特にインターフェース初期化フェーズ）への対応は確認されていません。
#132248 [wasm] Encode struct alignment in thunk signatures
- 作成者: @davidwrighton
- 作成日時: 2026年08月12日 23:24:58(UTC)
- マージ日時: 2026年08月15日 15:10:08(UTC)
- ラベル: area-ReadyToRun
概要
WebAssembly上で16バイト境界にアラインされた構造体の値渡しをサポートするPull Requestです。JIT インターフェイスのアラインメント計算を統合し、遷移thunkでアラインメント要件を検出する仕組みを導入しました。新たなエンコーディング（A<size>）を追加して16バイトアラインメント構造体を区別し、crossgenおよびWasm R2Rテストで検証しています。
変更内容
- ReadyToRun形式ドキュメント: 16バイトアラインメント構造体のエンコーディング仕様を追加
- JIT EEバージョンGUID: バージョン更新（
jiteeversionguid.h） - Wasm固有コンパイラロジック:
CompilerTypeSystemContext.Wasm.csでアラインメント計算を強化 - Wasm低下化処理:
WasmLowering.csでパラメータのアラインメント差異（8バイト vs 16バイト）を検出 - シグネチャマッピング:
SignatureMapper.csで新たなA<size>エンコーディングをサポート - テスト追加:
WasmArgumentLayoutTests.csとWasmR2RStructAlignment.csでアラインメント処理を検証 - ネイティブヘルパー:
wasm/helpers.cppでアラインメント対応のコード生成
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
- 内部実装の変更で、公開APIへの直接的な影響はありません
- WebAssembly向けのRuntimeのサポート向上に関連する変更です
- JIT EEバージョンGUID更新により、既存のコンパイル済みイメージとの互換性が変わります
#132033 Partition the ComWrappers RCW cache into per-processor buckets
- 作成者: @Sergio0694
- 作成日時: 2026年08月08日 07:00:06(UTC)
- マージ日時: 2026年08月15日 15:49:56(UTC)
- ラベル: area-System.Runtime.InteropServices tenet-performance community-contribution
概要
ComWrappers の RCW（Runtime Callable Wrapper）キャッシュをプロセッサ数に基づいて複数のバケットに分割し、単一の ReaderWriterLockSlim による競合を軽減する変更です。キャッシュエントリを WeakGCHandle<NativeObjectWrapper> に置き換え、型安全性と処理効率を向上させます。ネイティブ・マネージド間の遷移は非常にホットパスであり、特にファイナライザスレッドによる書き込みとアプリケーションスレッドによる読み込みの競合を解消することで、大幅なパフォーマンス向上が期待できます。
変更内容
ComWrappers.cs: RCW キャッシュをバケット配列に分割。各バケットは独立した
DictionaryとReaderWriterLockSlimを保有。バケット選択には Fibonacci ハッシュ（0x9E3779B97F4A7C15による乗算・シフト）を使用し、ポインタの低位ビットの偏りを補正。RcwCacheとBucketはreadonly structとしてComWrappers内にインライン化。GCHandleからWeakGCHandle<NativeObjectWrapper>に移行。Program.cs:
ComWrappersNoLockAroundQueryInterfaceテストを更新。異なる COM ポインタを使用していたため、パーティション化後に異なるバケットにマップされる可能性があった問題を修正。同じアイデンティティポインタを再利用し、同じバケック内での動作を保証。スレッド結合の成功を明示的にアサート。
パフォーマンスへの影響
改善効果（実測値）:
- CsWinRT 2.3.0 での単一オブジェクト構築: −7.4%～−10.5%
- CsWinRT 3.0.0 での単一オブジェクト構築: −2.4%～−8.1%
- 10,000 インスタンス構築（ガベージコレクション並行）: −6.3%～−12.4%
- Gen2 コレクション削減: −26%～−60%
- マイクロベンチマーク（32スレッド、キャッシュヒット）: 最大13.6倍高速化（0.07x～0.25x）
トレードオフ:
- 単一スレッド且つ大規模ワーキングセット（1024 RCW）での低下: +1%～+11%（キャッシュフットプリント増加による）
- ComWrappers インスタンスあたりのメモリ増加: 576 B → 6,536 B（32コア環境）。バケット数がプロセッサ数に比例。
関連Issue
なし
その他
- 実装の詳細: バケット数は
BitOperations.RoundUpToPowerOf2(Environment.ProcessorCount)で決定（ConcurrentDictionary の既定値に合致）。インデックス計算にマスク演算を使用し除算を回避。 - 検証: 3,461 個の相互運用テストが Checked CoreLib で合格。
RegisterWrapperForObjectのアサーションでキャッシュのバケット選択を直接検証。 - 内部実装の変更:
RemoveAllが原子的でなくなったが、呼び出し