Pull Request on 2026年08月25日

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

注意点

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

#132749 Fix TlsSessionTests TLS resume flakiness by using a unique SNI

  • 作成者: @rzikm
  • 作成日時: 2026年08月25日 14:14:41(UTC)
  • マージ日時: 2026年08月25日 17:23:39(UTC)
  • ラベル: area-System.Net.Security

概要

TLSセッションレジューム機能のテストで並列実行時のフレーキネスを修正しました。複数テストが共有するOpenSSLセッションキャッシュに対する競合状態を解決するため、クライアントのSNI(TargetHost)をテスト実行ごとに一意な値に変更します。テスト分離バグであり、製品コード上の問題ではありません。

変更内容

src/libraries/System.Net.Security/tests/FunctionalTests/TlsSessionTests.cs

  • ServerSession_TlsResume_HonorsAllowTlsResumeOptionテストメソッドのSNI値をサーバー証明書名からGuid.NewGuid().ToString("N")による一意な値に変更
  • MeasureHandshakeBytesAsyncメソッドのパラメータ名をserverNameからtargetHostに変更（意図明確化）
  • 呼び出し元の更新に対応

パフォーマンスへの影響

影響なし。テストのみの変更です。

関連Issue

#132111

その他

根本原因の詳細: Linuxでは、クライアント側のOpenSSLセッションキャッシュはプロセス全体のSSL_CTXに存在し、SNI名ごとに単一セッションを保持します。テスト群が並列実行される際、複数のテストが同一のSNI値で異なるサーバーに接続すると、一方のテストがもう一方にキャッシュされたセッションチケットを上書きしてしまい、チケット検証失敗時にpre_shared_key拡張を含む完全ハンドシェイクが発生します。この変動がテスト失敗の原因でした。既存のSslStreamTlsResumeTestsで採用されている同じ解決策を適用しています。

#132748 Update exception handling in SslStreamDisposeTest

  • 作成者: @rzikm
  • 作成日時: 2026年08月25日 13:51:20(UTC)
  • マージ日時: 2026年08月25日 17:47:38(UTC)
  • ラベル: area-System.Net.Security

概要

テスト SslStreamDisposeTest.Dispose_ParallelWithHandshake_ThrowsODE の例外ハンドリングロジックを更新しました。StreamBuffer.WriteAsync がインライン化される可能性があるため、スタックトレースから StreamBuffer.WriteAsync の代わりに ConnectedStreams.* の存在を確認するように変更することで、インライン化によるスタックトレース変化に対して堅牢になりました。

変更内容

  • src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamDisposeTest.cs
    • catch (InvalidOperationException) フィルタの例外検証ロジックを修正
    • スタックトレース検証対象を System.IO.StreamBuffer.WriteAsync から System.IO.ConnectedStreams に変更
    • テスト用の予期された InvalidOperationException を正しく認識可能に

パフォーマンスへの影響

影響なし（テストコードの例外ハンドリングロジックのみの変更）

関連Issue

なし

その他

この変更はテストの堅牢性を向上させるもので、ランタイムの最適化（メソッドインライン化）による副作用からテストを保護する目的です。本体コードへの変更ではなく、テストのみに影響します。

#132712 Enable PAL test result publishing token

概要

PALTestsのHelix送信ステップでテスト結果の公開を有効化し、Azure Pipelinesレポーターが正常に動作するようにする変更です。publishTestResults: trueを渡すことで、共通のsend-to-helix-step.ymlテンプレートがSYSTEM_ACCESSTOKENを正しく注入できるようになり、Helixワークアイテムのキューイング前に失敗していた問題を解決します。

変更内容

  • eng/pipelines/coreclr/templates/run-paltests-step.yml: PALTests送信ステップの呼び出しにpublishTestResults: trueパラメータを追加（+1/-0）
    • 他のランタイムHelix送信レグと同じくテスト結果公開を有効化

パフォーマンスへの影響

影響なし

関連Issue

#132545、#132614、#132656

その他

この変更はCI/CDパイプラインの構成修正であり、ランタイムコードの変更はありません。PALTests（Platform Abstraction Layer Tests）のHelixでの実行において、SYSTEM_ACCESSTOKENが未設定の状態で失敗していた問題に対応しています。

#132711 Reduce cDAC contract descriptor parser size

概要

cDAC（CoreDAC）のコントラクト記述子パーサーを、ソース生成型の JsonSerializer から直接 Utf8JsonReader を使用した実装に置き換え、バイナリサイズを削減します。コンパクト記述子形式、コメント、末尾のカンマ、入力検証、柔軟な数値解析などの機能は保持されます。

変更内容

  • ContractDescriptorParser.cs: ソース生成型JSONデシリアライゼーションを廃止し、Utf8JsonReaderを用いた直接パーサー実装に変更。辞書トークン解析をコントラクト、型、グローバル、サブ記述子で共有。未知のトップレベルプロパティは無視し、未使用の JsonElement 拡張データは保持しない。
  • ParserTests.cs: 未知のプロパティ、重複フィールド、オブジェクトおよびnullルート後の末尾JSONに対応するテストケースを追加（+51行）。
  • TargetTests.cs: マイナーな変更（+1/-1行）。

パフォーマンスへの影響

バイナリサイズ大幅削減：

  • mscordaccore_universal.dll（Release win-x64）: 6,097,408 → 5,483,520 bytes、削減幅 613,888 bytes（10.07%）
  • 削減の主要因：System.Text.Json、System.Private.CoreLib、System.Text.Encodings.Web およびコレクション関連アセンブリのサイズ縮小

実行時パフォーマンスについては提供情報に記載なし。

関連Issue

なし

その他

  • テスト：Microsoft.Diagnostics.DataContractReader.Tests で 3,097 件のテストが合格
  • 既知の問題：null の後の末尾コンテンツ、および不正な数値の例外仕様が不一致のため、修正が必要な2つのパーサーリグレッションが存在

#132705 [release/11.0] Ensure async validation tasks are cleaned up during initialization

概要

.NET 11で新たに導入された非同期DataAnnotations検証において、タスク生成時の失敗後に検証タスクがクリーンアップスコープの外で実行される可能性があった問題を修正します。この修正により、すべての開始されたタスクが制御を呼び出し元に返す前に確実にキャンセルおよび待機されるようになります。これはValidatorの公開APIの戻り値や検証順序には影響しません。

変更内容

  • System/ComponentModel/DataAnnotations/Validator.cs: タスク作成を既存のクリーンアップスコープ内に移動。これにより、タスクのセットアップ中に発生した例外の場合でも、すべての開始されたタスクが確実にキャンセルおよび待機されます。

パフォーマンスへの影響

影響なし。通常の検証結果またはタスク順序は変わりません。例外的なセットアップパスでは、元の例外を伝播する前に協力的でない検証タスクの完了を待つ可能性があります。

関連Issue

#132685

その他

  • 適用範囲: release/11.0ブランチへのバックポート
  • テスト結果: System.ComponentModel.Annotations.Testsは984件すべてのテストが合格
  • リスク評価: 低。変更はプライベートな実装ファイル1つのみで、公開APIは追加されていません
  • 背景: 非同期DataAnnotations検証は.NET 11で#128656により導入されたもので、この修正はその新機能のライフタイム保証を完成させるものです。.NET 10からの回帰ではありません

#132704 Fix cDAC server GC free region enumeration

概要

Server GC の cDAC（Compact Data Access Contract）モデルにおいて、GCHeapSVR.FreeRegions フィールドの取扱いを修正するPRです。

従来は free_regions をポインタとして扱っていたため、インライン配列の最初の要素の num_free_regions がアドレスとして誤解釈され、無効なメモリ読み取りが発生していました。このPRでは [FieldAddress] 属性を使用してインライン配列の基底アドレスを正しく取得するように変更します。

変更内容

  • GCHeapSVR.cs: FreeRegions フィールドの属性を [Field] から [FieldAddress] に変更し、インライン配列の正しいアドレスを取得するように修正
  • GCMemoryRegionTests.cs: Server GC インライン FreeRegions 列挙のユニットテストを追加（標準アーキテクチャ全体でカバー）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • テスト結果: Microsoft.Diagnostics.DataContractReader.Tests で 3,098 件のテストがパス
  • この変更は公開API ではなく、cDAC（ランタイムダイアグノスティックス機能）の内部実装の修正です
  • Server GC メモリ領域の列挙時に無効なメモリアクセスが発生していたバグの修正です

#132703 Remove commented ActiveIssue from SslKeyLogFile test

  • 作成者: @rzikm
  • 作成日時: 2026年08月24日 14:32:39(UTC)
  • マージ日時: 2026年08月25日 12:15:15(UTC)
  • ラベル: area-System.Net.Security

概要

System.Net.Securityの機能テストにおけるSslKeyLogFileテストから、不要になったコメント化されたアクティブIssueアトリビュートを削除するテストコードの整理です。OpenSSLがSSLKEYLOGFILE サポートを継続することが確認されたため、テストケースを無効化したままにすることが最適な対応方針となりました。

変更内容

  • src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamRemoteExecutorTests.cs: コメント化された[ActiveIssue]アトリビュート（1行）を削除

パフォーマンスへの影響

影響なし

関連Issue

#116473

その他

  • この変更はテスト実装に対する非機能的なクリーンアップであり、テスト実行には影響しません
  • OpenSSLのSSLKEYLOGFILE機能制御についてアプリケーションレベルのAPIが存在しないため、テストを無効化したままにすることが妥当な結論です

#132694 Fix SslStream detection of exactly-5-byte TLS frames

  • 作成者: @rzikm
  • 作成日時: 2026年08月24日 12:30:21(UTC)
  • マージ日時: 2026年08月25日 13:35:42(UTC)
  • ラベル: area-System.Net.Security

概要

SslStream.EnsureFullTlsFrameAsyncにおけるTLSフレーム検出のバグを修正。正確に5バイト（ヘッダーのみで0長ペイロード）のTLSレコード検出に失敗し、無限待機する問題を解決。フレームサイズ再計算の条件を>から>=に変更し、5バイト以上で即座に再計算するようになりました。

変更内容

  • SslStream.IO.cs: フレームサイズ再計算の条件を_buffer.EncryptedLength > TlsFrameHelper.HeaderSizeから_buffer.EncryptedLength >= TlsFrameHelper.HeaderSizeに修正。int.MaxValueリテラルをUnknownTlsFrameLength定数に置き換え
  • SslStreamFramingTest.cs: Read_ExactlyFiveByteTlsRecord_DetectedAsCompleteFrameテストを追加。5バイトのゼロ長ペイロードTLSレコードが正常に検出されることを検証

パフォーマンスへの影響

影響なし。この修正は無限待機を防ぐもので、パフォーマンス改善ではありません。修正前は最大60秒のタイムアウト待機、修正後は1秒以下で完了することが確認されています。

関連Issue

#132694

その他

  • 実際の暗号化されたレコードは絶対に5バイトにならない（AEAD暗号化オーバーヘッド）のため、テストでは人工的に5バイトレコードを注入して検証しています
  • このPRはGitHub Copilotにより作成されました

#132672 [release/11.0] Fix concurrent Reflection.Emit TypeLoadException (#129230)

概要

リリース11.0向けのバックポート。PR #130696で修正された並行処理下のReflection.Emit TypeLoadException問題をrelease/11.0ブランチに適用します。

変更内容

  • src/coreclr/md/compiler/emit.cpp: 4行削除
  • src/coreclr/md/compiler/regmeta_emit.cpp: 4行削除

具体的な削除内容は提供されていないため詳細は不明ですが、Reflection.Emit時の型読み込み処理に関連したコード削減と推定されます。

パフォーマンスへの影響

提供された情報では判断できません。

関連Issue

#129230 元のPR: #130696

その他

  • このバックポートはrelease/11.0ブランチを対象としています
  • レビュワーは@noahfalkです
  • @steveisokがこのPRにccされています
  • 提供されたテンプレートではCustomer Impact、Regression、Testing、Riskの詳細が入力されていないため、オリジナルのPR #130696を参照する必要があります

#132670 Delete JIT_GetDynamic{GC,NonGC}StaticBase_SingleAppDomain asm helpers

  • 作成者: @EgorBo
  • 作成日時: 2026年08月23日 14:28:24(UTC)
  • マージ日時: 2026年08月25日 15:53:53(UTC)
  • ラベル: area-VM-coreclr

概要

動的静的フィールドへのアクセスヘルパー（JIT_GetDynamic{GC,NonGC}StaticBase_SingleAppDomain）のアセンブリ実装をamd64/arm64/loongarch64/riscv64から削除し、すべてのプラットフォームで管理コード実装（StaticsHelpers）に統一しました。この変更により、コード重複を排除し、LoongArch64とRISC-Vのバグ（ビット0チェックの誤り）を同時に修正します。

変更内容

  • JIT ヘルパー定義削除：jitinterface.hからJIT_Get*StaticBaseシムを削除（NULL参照を排除）
  • プラットフォーム固有コード削除：
    • amd64/arm64/loongarch64/riscv64のアセンブリ実装を完全削除（.asm/.Sファイルから計~245行削除）
    • 各プラットフォームのasmconstants.h/cgencpu.hから関連定数を削除
    • グローバルポインタg_pGetGCStaticBase/g_pGetNonGCStaticBaseを削除
  • コンパイラ設定： CMakeLists.txtから関連ファイルの参照を削除

パフォーマンスへの影響

改善：

  • 高速パス：管理コード実装は23バイト（ビット0チェック+ret）で、アセンブリ版の~30バイトと同等
  • 遅延パス：管理実装はDynamicStaticsInfo*をMethodTableに再変換する必要がなく、直接GetNonGCStaticBaseSlowにテール呼び出し

バグ修正による改善：

  • LoongArch64/RISC-Vの誤り（bnezで全ポインタをテストしてビット0をチェックせず）を排除。初期化済みベースが毎回遅延パスを実行していた不具合を解消

関連Issue

#108167

その他

  • この変更は新しい正確性モデルではなく、x86/arm32では既に管理実装を使用していた状態（アセンブリ版は到達不可能だった）をすべてのプラットフォームで統一するもの
  • NativeAOTは既に同様のクラスコンストラクタ処理を管理コードで実装している
  • OFFSETOF__DynamicStaticsInfo__*アセンブリ定数がすべてのプラットフォームから削除される（4プラットフォーム×3定数）
  • *_NOCTORシムは引き続き_Portable実装に解決されるため保持

#132626 [release/10.0] Fix transition from monomorphic to polymorphic VSD

概要

arm64およびその他のアーキテクチャにおいて、Virtual Stub Dispatch (VSD)の単形から多形への遷移ロジックをx64と同じ実装に統一。arm64では共有ミスプリディクションカウンタの書き込みによるキャッシュコヒーレンスオーバーヘッドが高く、マルチコアマシンでスケーリングが大幅に制限されていた問題を修正。

変更内容

  • src/coreclr/vm/arm64/virtualcallstubcpu.hpp: VSD遷移ロジックの修正（+8/-4）
  • src/coreclr/vm/arm/stubs.cpp: ARM用スタブの調整（+13/-8）
  • src/coreclr/vm/loongarch64/virtualcallstubcpu.hpp: LoongArch64用VSD実装の統一（+9/-7）
  • src/coreclr/vm/riscv64/virtualcallstubcpu.hpp: RISC-V64用VSD実装の統一（+9/-7）

パフォーマンスへの影響

改善あり。arm64マルチコアマシン（32コア環境で検証済み）におけるVSDミスプリディクション処理でのキャッシュコヒーレンスオーバーヘッドを削減。スケーリング特性が大幅に向上。

関連Issue

#132544（オリジナルPR）

その他

本PRはrelease/10.0ブランチへのマニュアルバックポート。arm64の実装がx64から長期にわたって乖離していたため、同じロジックに統一することでアーキテクチャ間の一貫性も向上。リスク評価は低い。

#132528 Add R2R fixup for referencing a type via a method it declares

  • 作成者: @davidwrighton
  • 作成日時: 2026年08月19日 17:43:18(UTC)
  • マージ日時: 2026年08月25日 08:32:20(UTC)
  • ラベル: area-ReadyToRun

概要

メソッドがC#コンパイルとR2Rコンパイル間で派生クラスから基底クラスに移動され、基底クラスがモジュール内で参照不可の場合、型をシグネチャにエンコードできない問題を解決します。新しいREADYTORUN_FIXUP_DeclaringTypeHandleエンコーディングでは、エンコード不可な型シグネチャの代わりにメソッドシグネチャを使用し、そのメソッドを宣言する型に解決されます。

変更内容

  • Crossgen2コンパイラ側: CanEncodeTypeInSignatureで型がシグネチャにエンコード可能か検出し、不可の場合はDeclaringTypeHandleにフォールバック。3つのコンパイラパス（共有汎用辞書参照、スタンドアロンインポートセル、静的メソッドの隠し型引数）に対応
  • ランタイム側: Dictionary::PopulateEntryにDeclaringTypeHandleFromMethodSlotを追加し、LoadDynamicInfoEntryで対応するケースを実装。メソッドから宣言型を解決し、MethodDesc::GetExactDeclaringTypeで正確な具体化された祖先型を復元
  • R2R形式: 新辞書スロット種別DeclaringTypeHandleFromMethodSlot（fixup 0x2D）を追加、R2Rマイナーバージョンを26.2に更新
  • R2Rダンパー: バージョンゲートDeclaringTypeHandleFixupUsesMethodSignature（>= 26.2）を追加し、旧来の2つの型シグネチャペアとの互換性を維持
  • テスト: mainv3テスト設定を追加、メソッド移動シナリオを複数組み合わせでカバー（スタンドアロン/辞書参照×プレーンMemberRef/MethodSpec）

パフォーマンスへの影響

影響なし

関連Issue

#132416、#57614

その他

  • 破壊的変更：R2R形式のマイナーバージョン26→26.2への更新により、R2R 26ランタイムは新形式イメージを拒否
  • Crossgen1削除（R2R 5.4で実施）により、旧エンコーディング（ペアの型シグネチャ）との互換性はなく、フォーマット値の再利用は安全
  • 汎用MemberRefはactualTypeRequired: FALSEでもトークン参照所有者を保持、キャッシュ可能な非汎用MemberRefは既に正確な宣言型に解決
  • Windows x64 Debugのみ検証済み（クロスアーキテクチャ、Unix、NativeAOT未検証）

#132351 Fix X509 reference leak in SslStream extra chain certificates on Unix

概要

Unix環境のSslStreamにおけるX509参照リークの修正です。CryptoNative_SslAddExtraChainCertのOpenSSL呼び出しが不正な所有権セマンティクス（add1）を使用していたため、接続ごとに中間証明書の参照がリークしていました。SSL_CTRL_CHAIN_CERTの引数を1から0に変更し、add0セマンティクス（OpenSSLが呼び出し元の参照を取得）に統一することで修正します。

変更内容

  • src/libraries/Common/src/Interop/Unix/System.Security.Cryptography.Native/Interop.Ssl.cs
    • CryptoNative_SslAddExtraChainCert呼び出しのSSL_CTRL_CHAIN_CERTの引数をlarg=1からlarg=0に変更
    • 所有権契約と修正の必要性を説明するコメントを追加

パフォーマンスへの影響

重大なメモリリーク修正です。実測によると：

  • 修正前（stock）：800クライアント接続（各々1つの中間証明書を提示）で800個のX509がリーク、ネイティブメモリ増加率は約14 MiB/時間
  • 修正後（patched）：同条件でリーク0個、メモリ成長停止
  • 共有証明書コンテキスト使用時：修正前後とも蓄積なし（既存参照の再利用により）

特に長時間動作するサーバーアプリケーション（PostgreSQL接続など）で深刻で、本修正により完全に解決します。

関連Issue

#132350

その他

  • OpenSSL 3.5.7での実測値に基づいた修正
  • 修正は1バイト変更（mov $0x1,%edx → mov $0x0,%edx）で実装
  • ドットネットランタイムの構築・テストスイート実行は未実施（出荷済みバイナリに対する検証のみ）
  • ネイティブメモリリークはGC・dotnet-gcdumpでは検出不可（SetHandleAsInvalidでSafeHandleが無効化され、終了時までメモリが残存）

#132339 Implement ReadyToRun for CoreCLR browser-wasm

概要

CoreCLR向けブラウザ-wasm(実験的・オプトイン)にReadyToRun(R2R)実装を追加します。R2Rイメージはwebcil-in-wasmモジュール（アセンブリのECMAメタデータとcrossgen2生成のR2Rネイティブコード含有）として機能します。フレームワークの事前ビルドR2Rイメージ（181共有フレームワークアセンブリ）とアプリ固有の動的R2Rの両方をサポート。PublishReadyToRunはブラウザ-wasmでデフォルト無効です。

関連Issue: #121257、#132466

変更内容

1. Crossgen2ツール対応

  • jit/CMakeLists.txt: Webassemblyユニバーサル JIT（clrjit_universal_wasm）をalljitsにデュアルインストール

2. ランタイムパック生産側

  • Microsoft.NETCore.App.Runtime.CoreCLR.sfxproj: 共有フレームワークの各アセンブリをwebcil-in-wasm R2Rイメージに変換しnative/r2r/配下にパッケージ化。IL形式（lib/net11.0/*.dll）は修剪・リファレンス解決用に保持
  • ResolveReadyToRunCompilers.cs: wasmアーキテクチャおよびbrowser/wasiOS対応を追加

3. SDK消費側ターゲット

  • Microsoft.NET.Sdk.WebAssembly.Browser.CoreCLR.targets（新規）: CoreCLR固有のR2Rデフォルト設定、プローブディレクトリ選択、パッケージからの生R2Rの削除、発行順序制御
  • Microsoft.NET.Sdk.WebAssembly.Browser.targets: PrebuiltR2RDirectoryパラメータをConvertDllsToWebcilに追加

4. タスク拡張

  • ConvertDllsToWebcil.cs: オプションのPrebuiltR2RDirectoryパラメータ追加。修飾なしの非カルチャ.dllでマッチングR2Rイメージをプローブし、IL変換の代わりにステージング
    • プローブ順：.dll→.wasm（同名の非R2Rイメージを回避）
    • アセンブリバージョンガード実装（シャドウアセンブリの置換防止）

5. 段階的な実装分割

  • 提供されるのはテスト時スモークテストとして機能するSystem.Runtime.InteropServices.JavaScript.Tests（PublishReadyToRun=true）
  • インツリー用：WasmApp.InTree.props、WasmApp.ReadyToRun.targets、BrowserWasmApp.CoreCLR.targetsで修剪IL環境時のメタデータ読み込みを対応

パフォーマンスへの影響

測定値（Release）: 181アセンブリで90.6 MB R2R vs 15.4 MB IL（CoreLibが29 MB支配的）。IL形式比で約5.9倍のサイズだが、起動・実行時パフォーマンスの改善が期待される（具体的数値は提供なし）。

**

#132247 Add proposal doc for specifying load context for native hosting

  • 作成者: @elinor-fung
  • 作成日時: 2026年08月12日 23:24:45(UTC)
  • マージ日時: 2026年08月25日 22:17:57(UTC)
  • ラベル: area-Host

概要

ネイティブホスティングAPIで複数のコンポーネント（カスタムホスト、COM、C++/CLI）を非デフォルトAssemblyLoadContext（ALC）にグループ化できるようにするための設計提案ドキュメントを追加しました。現在のホスティングデリゲートはデフォルトALCまたは分離ALCのみをサポートしており、複数コンポーネント間での共有ALC利用ができない課題に対応します。

変更内容

  • docs/design/features/native-hosting-load-context.md（新規作成、78行）
    • load_context構造体による負荷コンテキスト識別子の提案
    • COM/C++/CLI MSBuildホストプロパティを含むコンポーネント毎のロードコンテキスト識別子の仕様
    • ALCの作成・追跡と順序付きAssemblyDependencyResolverによる依存関係解決の実行時動作の記述

パフォーマンスへの影響

影響なし（設計提案ドキュメントのため）

関連Issue

なし

その他

  • レビューでは2つのコメント指摘あり：
    1. コードサンプルで使用されている_X(...)マクロの明確化が必要（nethost.h/hostfxr.hの標準APIには含まれない内部マクロ）
    2. MSBuildホストプロパティ名が完全修飾名（System.Runtime.InteropServices.COM.LoadComponentInDefaultContextなど）で統一すべき
  • これは設計ドキュメントの段階であり、実装は別途PRで行われる予定と考えられます

#132099 Add TARGET_HAS_MULHI and TARGET_MASKS_SHIFTS flags to jit lowering

概要

JIT低レイヤーの処理をクリーンアップするため、2つの新しいターゲットフラグを追加するもの。PR #131909の後続作業として、TARGET_HAS_MULHI（乗算上位ビット命令のサポート）とTARGET_MASKS_SHIFTS（マスク・シフト命令のサポート）フラグを導入し、ターゲットアーキテクチャ別に定義します。

変更内容

  • lower.cpp: フラグ参照ロジックを簡潔化（5行追加、6行削除）
  • 各ターゲットヘッダファイル: 以下のフラグ定義を追加
    • TARGET_HAS_MULHI: x86, x64, arm64, loongarch64, riscv64で有効
    • TARGET_MASKS_SHIFTS: x86, x64, arm, arm64, loongarch64, riscv64, wasmで有効

各ターゲット定義ファイル（targetamd64.h, targetarm.h, targetarm64.h, targetloongarch64.h, targetriscv64.h, targetwasm.h, targetx86.h）に対応するフラグマクロを追加

パフォーマンスへの影響

影響なし（リファクタリングのみ）

関連Issue

#131909（先行PR）

その他

なし

#131969 Update Helix Job Monitor and turn it on for the runtime pipeline

  • 作成者: @mmitche
  • 作成日時: 2026年08月06日 21:12:40(UTC)
  • マージ日時: 2026年08月25日 15:13:45(UTC)
  • ラベル: area-Meta

概要

Helix Job Monitor ツールを 11.0.0-beta.26424.2 にアップデートし、runtime パイプラインで有効化します。このアップデートは dotnet/arcade#17331 からのスケーラブルな結果処理の書き直しを取り込み、ビルドスコープの検出、並列インクリメンタル結果アップロード、リトライ対応の状態管理、レート制限処理、最終ドレイン/ステータス報告を実装します。並列処理能力を 48 に設定し、パスフィルタリングされたビルドで Helix 投入がない場合もサポートします。

変更内容

  • .config/dotnet-tools.json: microsoft.dotnet.helix.jobmonitor のバージョンを 11.0.0-beta.26404.8 から 11.0.0-beta.26424.2 に更新
  • eng/common/core-templates/job/helix-job-monitor.yml: 結果アップロードの並列処理設定テンプレートロジックを追加（7行追加）
  • eng/pipelines/runtime.yml: runtime パイプラインで Helix Job Monitor を有効化し、結果アップロード並列処理を 48 に設定

パフォーマンスへの影響

並列インクリメンタル結果アップロード機能により、結果処理のスループット向上が期待されます。並列処理数 48 での具体的なベンチマーク数値は提供されていません。

関連Issue

なし

その他

Copilot レビューで eng/pipelines/runtime.yml の変数定義の重複が指摘されています（enableHelixJobMonitor が同じブロック内で2度定義されており、2番目の定義が1番目をオーバーライドしている）。

#131913 Remove unsafe code from number parsing and formatting

概要

数値解析・フォーマット処理全体におけるポインタベースのunsafeコードをSpan/ReadOnlySpanベースの実装に置き換えた大規模なセーフティ改善。NumberBuffer、数値型、DateTime、TimeSpan、Decimal浮動小数点型、BigIntegerなどのコア処理からポインタ操作を排除し、メモリ安全性を向上させながらパフォーマンスを維持・改善。

変更内容

  • Number.Formatting.Common.cs / Number.Parsing.Common.cs: ポインタ範囲スキャンをSpan+インデックススキャンに変更、二桁ライター/テーブルの追加
  • Number.NumberBuffer.cs: DigitsPtrを削除し、完全にSpanベースに移行（unsafeコード廃止）
  • Number.Formatting.cs / Number.Parsing.cs: 整数/小数/浮動小数点のフォーマット・解析ヘルパーをポインタから解放
  • DateTimeFormat.cs / TimeSpanFormat.cs: ポインタ書き込みをSpanスライス/ビルダーパターンに変更
  • Number.NumberToFloatingPointBits.cs: ポインタベースの数字解析をSpanスライスとBinaryPrimitivesベースの読み込みに置き換え
  • Decimal32/64/128.cs: 仮数抽出をポインタからSpanスライスに変更
  • BigInteger.cs（両方のリポジトリ）: 解析/フォーマット経路からunsafeを除去、Span基盤のライターを導入
  • DateTimeParse.cs: ParseByFormatシグネチャからunsafeを削除

残存する低レベル操作（FastAllocateString、Unsafe.BitCast、MemoryMarshal.Write、Unsafe.SkipInit）は狭い範囲で明示的に監査済み。ポインタライター、pinning、fixedステートメントは対象経路から完全排除。

パフォーマンスへの影響

改善率（Candidate / Baseline、低いほど良好）:

  • Double解析: 0.86-0.91x ✓
  • 指数フォーマット: 0.91-0.95x ✓
  • Hex浮動小数点フォーマット: 0.71-0.78x ✓
  • DateOnly Rフォーマット: 0.66x ✓
  • BigInteger解析/フォーマット: 一般的に0.94-0.97x ✓
  • デフォルト整数10進フォーマット: ニュートラル～約24%高速化 ✓
  • 明示的な整数D/X/Bフォーマット: ニュートラルまたは高速、UInt128 Bは約1%以内のノイズ
  • グループ化/カスタムSpanフォーマット: 最大約1.10x
  • TimeSpan標準フォーマット: 約1.03-1.07x

82ベンチマーク行列全体でメモリアロケーション増加なし。2,266テストケースでバイト同一出力を確認。

関連Issue

#10397

その他

  • 互換性: 内部実装の変更であり、パブリックAPI破壊なし
  • テスト: System.

#131866 Enable browser-wasm runtime tests that require native library relinking

概要

WebAssemblyではネイティブライブラリの動的ロードがサポートされていないため、テストがネイティブライブラリを持つ場合、browser-wasmで実行できていませんでした。このPRは、テスト固有のcorerun.js/corerun.wasmを生成して、ネイティブライブラリを静的リンクすることで、browser-wasmランタイムテストの実行を可能にします。12個のプロジェクトで新たに18個のテストメソッドが実行されるようになります。

変更内容

コアインフラ：

  • src/coreclr/hosts/corerun/wasm/testkit.cmake - corerunのリンク閉包をエクスポートするブラウザ-wasmビルドキット
  • src/tests/Common/CLRTest.WasmCorerun.targets - テストごとにP/Invoke呼び出しテーブルを生成し、ManagedToNativeGeneratorタスクを実行してテスト固有のcorerunをリンク
  • eng/wasm/WasmPInvokeModules.props - フレームワークP/Invokeモジュールリストを一元管理（app-relinkパスとテストパスで共有）

テスト実行：

  • src/tests/Common/CLRTest.Execute.Bash.targets/CLRTest.Execute.Batch.targets - テスト固有のcorerun.jsを優先的に使用し、__TestNativeAssetsLinked=trueをエクスポート
  • src/tests/Common/CoreCLRTestLibrary/PlatformDetection.cs - __TestNativeAssetsLinked環境変数でネイティブアセット依存テストの実行を制御

ビルド構成：

  • src/tests/CMakeLists.txt - ${TEST_LIB_TYPE}を定義（wasmでSTATIC、他はSHARED）し、wasmフレーバーベースでツリー走査を制限
  • src/tests/build.sh/build.cmd - CMakeにCMAKE_BUILD_RUNTIME_FLAVORを転送
  • eng/pipelines/common/templates/runtimes/run-test-job.yml - browser run-testジョブにprovision.emsdk+tasksステップを追加（em++と一致するWasmAppBuilderが必要）

テストメタデータ：

  • 41個のプロジェクトにWasmBuildTestCorerun=falseを設定し、サポートされていない相互運用パターン（多フィールド構造体、reverse-P/Invokeデリゲート、undefined symbols等）を明示的に除外

修正：

  • src/tests/JIT/interpreter/Interpreter.cs - writeToStdout P/Invoke署名を修正（intからvoidに）

パフォーマンスへの影響

テスト固有のcorerunは約7 MBの.wasm + 280 KBの.jsで、サイズはCORE_ROOT/corerun.wasmと同等です。12個のテスト向けcoreruntimeで合計約85 MBがブラウザテストアーティファクトとHelixペイロードに追加されます。これは静的リンクを必須とするプラットフォーム特性上不可避な設計トレードオフです。

影響なし（実行性能）

関連Issue

#131811（5つの

目次