Pull Request on 2026年02月28日

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

注意点

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



#125011 Link pthread on OpenBSD

  • 作成者: @sethjackson
  • 作成日時: 2026年02月28日 15:30:57(UTC)
  • マージ日時: 2026年02月28日 20:10:21(UTC)
  • ラベル: area-System.Threading community-contribution os-openbsd

概要

OpenBSD環境でpthreadライブラリをリンクするための変更です。System.Nativeネイティブライブラリのビルド設定を修正し、OpenBSD上でpthread機能を正常に利用できるようにしています。

変更内容

  • src/native/libs/System.Native/extra_libs.cmake: OpenBSD向けのビルド設定にpthreadライブラリのリンク指定を追加(+2行)

パフォーマンスへの影響

影響なし。ビルド設定の修正のため、ランタイムパフォーマンスへの直接的な影響はありません。

関連Issue

なし

その他

  • OpenBSD固有の対応です。他のプラットフォーム(Linux、Windows等)への影響はありません
  • System.Nativeはランタイムが使用するネイティブライブラリであり、この修正によりOpenBSD上での基本的なシステム機能(スレッド処理など)が正常に動作するようになります

#125006 MachObjectWriter: Fix calculation of segment file offset and size

  • 作成者: @filipnavara
  • 作成日時: 2026年02月28日 08:39:08(UTC)
  • マージ日時: 2026年02月28日 16:22:09(UTC)
  • ラベル: area-crossgen2-coreclr community-contribution

概要

Mach-O形式のセグメントヘッダー計算に関するバグを修正しました。セグメントのファイルオフセットが最初のセクションのアラインされたオフセットに設定されておらず、ファイルサイズがローダーコマンドを誤って含めていたため、filesize > vmsizeという不正な状態が発生していました。この修正により、llvm-objdumpllvm-readobjなどのツールでの検証エラーが解消されます。

変更内容

  • MachObjectWriter.cs: LayoutSectionsメソッドを拡張し、セグメント内最初のセクションのアラインされたファイルオフセットを計算・戻り値に追加
  • セグメントファイルサイズの計算を修正:(最後のセクション終端 - セグメントファイルオフセット)として再計算(ヘッダ/ローダーコマンドを除外)
  • LC_SEGMENT_64ヘッダー出力時に新しい計算値を適用

パフォーマンスへの影響

影響なし(計算ロジックの修正であり、実行時性能への変化なし)

関連Issue

  • Fixes #124982
  • 代替案:#124985

その他

このバグはMach-O形式の生成時に特に重要です。セグメントヘッダーの不正な値はバイナリ解析ツールで拒否される可能性があったため、.NET Coreのネイティブコード生成(特にARM64やその他のプラットフォーム)における互換性向上に寄与します。


#124999 Fix src/minipal/thread.h on OpenBSD

  • 作成者: @sethjackson
  • 作成日時: 2026年02月28日 02:04:06(UTC)
  • マージ日時: 2026年02月28日 20:31:42(UTC)
  • ラベル: area-System.Threading community-contribution os-openbsd

概要

OpenBSD上でのpthread_set_name_np関数の使用方法に対応するため、src/minipal/thread.hを修正しました。OpenBSDでは同関数が戻り値を返さないという仕様の違いを考慮した条件分岐を追加しています。

変更内容

  • src/native/minipal/thread.h: OpenBSD固有のpthread_set_name_np呼び出し処理を追加(+6行、-1行)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

この変更はOpenBSDプラットフォーム対応の改善です。pthread_set_name_npの戻り値の有無がOSごとに異なるため、プラットフォーム固有の条件分岐によって対応しています。


#124995 Fix StackOverflowException from deeply nested character class subtractions

  • 作成者: @danmoseley
  • 作成日時: 2026年02月28日 00:32:57(UTC)
  • マージ日時: 2026年02月28日 06:57:09(UTC)
  • ラベル: area-System.Text.RegularExpressions

概要

深くネストされた正規表現の文字クラス減算([a-[b-[c-[...]]]])により、パーサーとRegexCharClassメソッドが再帰呼び出しされることで、キャッチ不可能なStackOverflowExceptionが発生し、プロセスが終了する問題を修正しました。再帰処理を反復処理に変換することで、すべての正規表現モード(NoneCompiledNonBacktracking)に対応しています。

// 修正前:深いネストで StackOverflowException
var pattern = "[a-[b-[c-[d-[e-[...深いネスト...]]]]]]";
var regex = new Regex(pattern); // クラッシュ

// 修正後:安全に動作
var pattern = "[a-[b-[c-[d-[e-[...10000階層まで...]]]]]]";
var regex = new Regex(pattern); // 成功

変更内容

  • RegexParser.cs: ScanCharClassメソッドを再帰から反復処理に変更。親スタック(List)を使用して、ネストされた減算を処理
  • RegexCharClass.cs: 3つのメソッドを反復処理に変換
    • ToStringClass: do/whileループで_subtractorを走査
    • CharInClassRecursiveCharInClassIterative: トグルベースのwhileループで各レベルの一致を切り替え
    • Parse: 減算チェーンを前方反復で構築
  • テスト追加: 深いネスト(10,000階層)、正確性、大文字小文字の区別、否定された外部クラスなど複数のシナリオをカバー

パフォーマンスへの影響

改善点:

  • スタックオーバーフローの回避により、深くネストされたパターン(10,000階層まで)での正常な動作が実現
  • メモリ効率向上:明示的なスタック(List<RegexCharClass>)はヒープ上で管理されるため、呼び出しスタックの圧力が軽減

懸念点:

  • 浅いネスト(一般的なパターン)でのパフォーマンス変化は想定されません。反復処理は再帰と同等の計算量です

関連Issue

Issue #124995

その他

  • キャラクタークラス減算はRegexParser唯一の再帰的パース経路でした。グループ((((...))))などの他のネスト可能な構文は既に反復処理(PushGroup/PopGroupによる明示的スタック)で実装されていました
  • 公開API変更なし。内部実装のみの修正
  • すべての正規表現モード(CompiledSourceGeneratedNonBacktracking)で同じ修正が適用されます

#124991 Fix pal_error_common.h on OpenBSD

  • 作成者: @sethjackson
  • 作成日時: 2026年02月27日 22:39:07(UTC)
  • マージ日時: 2026年02月28日 04:12:48(UTC)
  • ラベル: area-PAL-coreclr community-contribution os-openbsd

概要

OpenBSD環境でEMULTIHOPENOLINKエラー定数が存在しないため、これらの定数をプラットフォーム固有で定義する修正です。pal_error_common.hにOpenBSD向けの条件付きコンパイルディレクティブを追加し、該当する環境でのビルドエラーを解決します。

変更内容

  • src/native/libs/Common/pal_error_common.h: OpenBSD環境でのエラー定数定義を追加(+8行)
    • EMULTIHOPENOLINKに対するOpenBSD互換性対応

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このPR は OpenBSD への .NET ランタイムの移植性を向上させるプラットフォーム固有の修正です。OpenBSD でのネイティブライブラリのビルドが正常に完了できるようになります。


#124988 Localized file check-in by OneLocBuild Task: Build definition ID 679: Build ID 2914804

  • 作成者: @dotnet-bot
  • 作成日時: 2026年02月27日 20:48:56(UTC)
  • マージ日時: 2026年02月28日 09:09:22(UTC)
  • ラベル: area-Extensions-Logging

概要

OneLocBuild の自動化プロセスによる多言語リソースファイルの定期チェックイン。Microsoft.Extensions.Logging.Abstractions ライブラリの XLF(XLIFF)形式の翻訳ファイルが更新されています。13言語のローカライズ済みリソースファイルが同期されました。

変更内容

  • 対象ライブラリ: Microsoft.Extensions.Logging.Abstractions/gen/Resources/xlf/
  • 変更ファイル: 13個の言語別 XLF ファイル
    • Strings.cs.xlf(チェコ語)
    • Strings.de.xlf(ドイツ語)
    • Strings.es.xlf(スペイン語)
    • Strings.fr.xlf(フランス語)
    • Strings.it.xlf(イタリア語)
    • Strings.ja.xlf(日本語)
    • Strings.ko.xlf(韓国語)
    • Strings.pl.xlf(ポーランド語)
    • Strings.pt-BR.xlf(ブラジルポルトガル語)
    • Strings.ru.xlf(ロシア語)
    • Strings.tr.xlf(トルコ語)
    • Strings.zh-Hans.xlf(中国語簡体字)
    • Strings.zh-Hant.xlf(中国語繁体字)
  • 各ファイルで 6~7行の追加・削除(翻訳内容の更新)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRは 自動生成 されたものであり、OneLocBuild タスクによる定期的なローカライズファイル同期プロセスの一部です
  • 翻訳品質上の問題がある場合は、https://aka.ms/icxLocBug でバグ報告が必要です
  • XLF ファイルは XLIFF 2.0 形式のリソースファイルで、複数言語のローカライズをサポートする標準形式です

#124987 Bump rollup from 4.52.2 to 4.59.0 in /src/native

  • 作成者: @dependabot[bot]
  • 作成日時: 2026年02月27日 20:20:09(UTC)
  • マージ日時: 2026年02月28日 09:06:54(UTC)
  • ラベル: area-Infrastructure javascript dependencies

概要

dotnet/runtimeの/src/nativeディレクトリにおいて、JavaScriptモジュールバンドラーのrollupを4.52.2から4.59.0にバージョンアップしたマイナーバージョン更新です。セキュリティ脆弱性の修正(Windows上のヒープ破損問題など)と機能改善が含まれています。

変更内容

  • package.json: rollup依存関係を4.52.2 → 4.59.0に更新
  • package-lock.json: ロックファイルを同期(+137/-92行)

パフォーマンスへの影響

4.58.0に含まれる「コード文字列の不要なクローンを回避する」最適化により、バンドル生成時のメモリ効率が向上する可能性があります。その他のパフォーマンスへの顕著な影響は報告されていません。

関連Issue

  • Rollup #6251: Windows上のヒープ破損問題の修正
  • Rollup #6254: try...catch内の動的インポートのエクスポート処理改善
  • Rollup #6276: バンドルが出力ディレクトリを超えるパスを生成する場合のエラー検出機能追加

その他

  • インストール時に実行されるprepareスクリプトが変更されているため、更新前に確認が推奨されます
  • 新しいリリーザー(GitHub Actions)によってnpmに公開されています
  • 複数のバグ修正と依存関係の更新が含まれています(lru-cache v11への更新、SWC Rust依存関係の更新など)

#124983 [cDAC] Fix com lifetime bug in GetHandleEnum

  • 作成者: @rcj1
  • 作成日時: 2026年02月27日 19:03:07(UTC)
  • マージ日時: 2026年02月28日 02:21:32(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

cDAC(Common DAC)の GetHandleEnum および GetHandleEnumForTypes メソッドにおけるCOM参照カウント(refcount)の不一致を修正しました。レガシーDAC実装と同様に、QueryInterface経由で列挙子を返す際に参照カウントをインクリメントするよう改善されています。

変更内容

  • src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs
    • GetHandleEnum メソッド:SOSHandleEnum 構築後にCOM参照カウントをインクリメント
    • GetHandleEnumForTypes メソッド:SOSHandleEnum 構築後にCOM参照カウントをインクリメント

パフォーマンスへの影響

影響なし。参照カウント管理のみの変更で、実行時パフォーマンスへの直接的な影響はありません。

関連Issue

  • Azure Pipelines ビルド結果:https://dev.azure.com/dnceng-public/public/_build/results?buildId=1311638

その他

本修正はCOM lifetime バグであり、不適切な参照カウント管理によるメモリリークやオブジェクト破棄タイミングの問題を解決しています。cDACの動作をレガシーDAC実装と一致させることで、互換性と安定性が向上します。


#124975 Introduce DOTNET_JitReportMetrics

  • 作成者: @Copilot
  • 作成日時: 2026年02月27日 14:53:35(UTC)
  • マージ日時: 2026年02月28日 03:14:25(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT メトリクス報告機能を制御する新しい環境変数 DOTNET_JitReportMetrics を導入しました。従来は DEBUG ビルド時に無条件でメトリクスを報告していましたが、この変更により必要に応じてのみ報告するようになり、不要な JIT-EE 呼び出しのオーバーヘッドを削減できます。SuperPMI は特別扱いで常に報告機能を有効化します。

// 使用例: 環境変数で制御
// DOTNET_JitReportMetrics=1 で有効化
if (JitConfig.JitReportMetrics())
{
    Metrics.report(this);
}

変更内容

ファイル 変更内容
jitconfigvalues.h RELEASE_CONFIG_INTEGER(JitReportMetrics, "JitReportMetrics", 0) を追加
jitmetadata.cpp JitMetadata::reportreportValueJitMetrics::report#ifdef DEBUG の外に移動し、リリースビルドでも利用可能に
compiler.cpp Metrics.report(this) をメトリクス設定値でゲート化; Metrics.BytesAllocated 計算もメトリクス有効時のみ実行
superpmi/jithost.cpp JitReportMetrics を特別扱いして常に 1 を返す
superpmi-shim-collector/jithost.cpp JitReportMetrics をメソッドコンテキスト収集から除外

パフォーマンスへの影響

改善点:

  • DEBUG ビルド時に毎メソッドで実行されていた O(metrics) 件数の JIT-EE 呼び出しを削減可能
  • メトリクス不要時のアリーナページウォークオーバーヘッドを回避(BytesAllocated 計算を条件化)
  • デフォルト設定 (DOTNET_JitReportMetrics=0) では報告機能が無効化され、既存の性能特性を維持

関連Issue

なし

その他

  • 本 PR は #124943 から JIT 関連部分を抽出した独立 PR
  • SuperPMI の memorydiff 機能がリリースビルドの JIT バイナリを使用するため、メトリクス報告機能をリリースビルドでも利用可能にする必要があった
  • 破壊的変更なし(デフォルト値により既存動作を維持)

#124953 Remove ActiveIssue from src/tests/JIT/jit64/regress/vsw/373472/test.il

  • 作成者: @akoeplinger
  • 作成日時: 2026年02月27日 09:41:31(UTC)
  • マージ日時: 2026年02月28日 07:01:16(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT回帰テスト(vsw/373472)から誤って再追加されたActiveIssueAttributeを削除するPull Requestです。WASM プラットフォーム向けのテスト無効化を解除し、Apple モバイルプラットフォーム向けの既存の除外設定は維持されます。

変更内容

  • src/tests/JIT/jit64/regress/vsw/373472/test.il
    • PlatformDetection.IsWasmに対するXunit.ActiveIssueAttributeを削除(5行削除)
    • PlatformDetection.IsAppleMobileに対する既存のActiveIssueAttributeは変更なし

パフォーマンスへの影響

影響なし(テスト管理の変更のため)

関連Issue

PR #124778で誤って再追加されたことが原因

その他

  • このテストは WASM プラットフォーム上での実行が可能になります
  • Apple モバイルプラットフォーム向けの除外設定は引き続き有効です
  • テストの実装内容自体への変更はなく、テスト実行可否の設定のみの修正です

#124944 Delete ArrayEEClass - compute multidim array rank from BaseSize

  • 作成者: @Copilot
  • 作成日時: 2026年02月27日 05:49:08(UTC)
  • マージ日時: 2026年02月28日 16:13:23(UTC)
  • ラベル: area-VM-coreclr

概要

ArrayEEClass (メタデータクラス) を削除し、多次元配列のランク情報を MethodTable::BaseSize から計算するように変更しました。ArrayClass は単にランクのみを保持していたため、既に BaseSize に エンコードされている情報は冗長でした。この変更により、CoreCLR が NativeAOT と同じアプローチに統一されます。

// ランク計算の例
DWORD boundsSize = GetBaseSize() - ARRAYBASE_BASESIZE;
DWORD rank = boundsSize / (sizeof(DWORD) * 2);

変更内容

CoreCLR VM (C++)

  • class.h: ArrayClass クラス定義を完全削除、PTR_ArrayClass 型定義も削除
  • methodtable.inl: GetRank()BaseSize からランクを計算するように実装変更
  • array.cpp: ArrayClass メンバー関数を静的関数に変更、EEClass 直接割り当て
  • object.inl, methodtable.cpp: GetRank() の直接呼び出しに統一
  • datadescriptor.inc: ArrayBaseSize グローバル定数をエクスポート追加

cDAC (Managed & Tests)

  • DataType.ArrayClassData.ArrayClass を削除
  • RuntimeTypeSystem_1.IsArray() が新しい ArrayBaseSize グローバル値を使用してランク計算
  • モックディスクリプタとテストを更新、BaseSize からランク導出を検証する新テスト ValidateMultidimArrayRank を追加

パフォーマンスへの影響

メモリ効率改善: ArrayEEClass インスタンス (最小 1 バイト) の割り当てが削除され、配列オブジェクト作成のメモリ使用量が削減されます。ランク取得時の計算コストは軽微 (単純な算術演算) で、キャッシュ効率も向上します。

関連Issue

なし

その他

  • 互換性への影響: 内部実装変更であり、公開 API への破壊的変更なし
  • friend class NativeImageDumper 宣言が 4 か所で削除されました
  • NativeAOT との設計統一により、将来的なコード保守性が向上

#124933 Add GetSyncBlockData cDAC API

  • 作成者: @rcj1
  • 作成日時: 2026年02月27日 01:14:04(UTC)
  • マージ日時: 2026年02月28日 07:37:32(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

cDAC(Common Data Access Contract)に GetSyncBlockData API を追加し、SyncBlock情報の診断アクセスを可能にするPull Requestです。SyncBlockはオブジェクトの同期情報を管理する重要なランタイム構造体であり、このAPIを通じてデバッガやプロファイラが同期状態やロック情報を読み取れるようになります。

// ISyncBlock.cs - 新規インターフェース
public interface ISyncBlock : IContract
{
    TargetPointer GetSyncBlock(uint number);
    TargetPointer GetSyncBlockObject(uint number);
    // その他メソッド定義
}

変更内容

  • 新規ファイル: ISyncBlock.cs インターフェース定義、SyncBlock_1.cs 実装、複数のデータ構造体(SyncBlock.csSyncBlockCache.csSLink.csSyncTableEntry.csInteropSyncBlockInfo.cs
  • 更新ファイル:
    • datadescriptor.inc: データディスクリプタにSyncBlock関連の定義を追加
    • syncblk.h: ネイティブSyncBlock構造体の定義更新
    • SOSDacImpl.cs: GetSyncBlockData メソッド実装(約82行追加)
    • ISOSDacInterface.cs: 新規API仕様定義
    • Object.mdSyncBlock.md: ドキュメント追加・更新
  • テスト追加: tests/DumpTests/Debuggees/SyncBlock/ に診断テストケース追加

パフォーマンスへの影響

影響なし。本変更は診断・デバッグAPI層の拡張であり、ランタイムのメインパスには影響しません。SyncBlock情報の読み取りはオンデマンドでのみ発生します。

関連Issue

#124933

その他

Copilotレビューで以下の軽微な改善提案あり(未実装の可能性):

  • ISyncBlock.cs: namespace宣言後に空行を追加(コード規約統一)
  • SyncBlockFactory.cs: 未使用の using System; を削除
  • SOSDacImpl.cs: null判定パターンマッチの冗長性を排除

本変更はcDACの拡張性を示す重要なPRで、診断インフラストラクチャの継続的な強化を示しています。


#124878 Adjust how we access thread ID for header thin locks

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年02月26日 00:39:49(UTC)
  • マージ日時: 2026年02月28日 16:44:49(UTC)
  • ラベル: area-VM-coreclr

概要

Thin Lock実装におけるスレッドID取得の最適化。従来のプリコンパイルされたスレッドID(DWORD tid)ではなく、Thread*ポインタを渡し、スレッドIDが必要なコードパスでのみGetThreadId()を呼び出すように変更。これによりCPUのパイプライン性能向上を目指し、.NET 11の生成アセンブリを.NET 10に近づけることで性能回復を実現。

// 変更前: スレッドIDを事前計算
AcquireHeaderThinLock(GetThread()->GetThreadId());

// 変更後: Thread*ポインタを渡す
AcquireHeaderThinLock(GetThread());
// GetThreadId()は必要なパスでのみ呼び出し

変更内容

  • src/coreclr/vm/syncblk.h: AcquireHeaderThinLock()ReleaseHeaderThinLock()のシグネチャをDWORD tidからThread* pCurThreadに変更
  • src/coreclr/vm/syncblk.inl: メモリアクセス分離を改善するため、GetThreadId()呼び出しを条件分岐内に移動。必要なコードパスでのみ呼び出し
  • src/coreclr/vm/comsynchronizable.cpp: 呼び出し元を更新しGetThread()を直接渡すように修正

パフォーマンスへの影響

改善の見込み: メモリアクセスパターンの最適化により、CPUキャッシュとパイプラインの効率向上を期待。.NET 10と.NET 11のアセンブリ出力がほぼ同一水準に近づき、コンパイラが不要なメモリロードを削減可能。

関連するパフォーマンス課題(#64673、#121350)の性能低下回復を目指す。具体的なベンチマーク結果はPR説明に明記なし。

関連Issue

その他

内部実装の最適化であり、公開APIへの影響なし。Lock acquire/releaseの基本ロジックに変更なく、呼び出し規約の最適化のみ。


#124830 Fix Directory.Delete(path, recursive: true) failing on directories containing junctions

  • 作成者: @Copilot
  • 作成日時: 2026年02月24日 22:02:40(UTC)
  • マージ日時: 2026年02月28日 07:41:43(UTC)
  • ラベル: area-ExceptionHandling-coreclr

概要

Windows上でDirectory.Delete(path, recursive: true)を実行する際、NTFSジャンクション(ディレクトリジャンクション)を含むディレクトリ削除が失敗する問題を修正しました。ジャンクションとボリュームマウントポイントが同じリパースタグ(IO_REPARSE_TAG_MOUNT_POINT)を共有していることが原因で、DeleteVolumeMountPointの失敗がジャンクション削除時も発生していました。エラーハンドリングを改善し、RemoveDirectoryが成功する場合はエラーを無視するようにしました。

// 修正前:DeleteVolumeMountPoint失敗がexceptionを汚染してRemoveDirectoryの成功を妨ぐ
// 修正後:エラーを一時変数に段階化し、RemoveDirectoryも失敗した場合のみ昇格
Exception? mountPointException = null;
if (!Interop.Kernel32.DeleteVolumeMountPoint(mountPoint))
    mountPointException = ...; // 一時的に段階化

if (!Interop.Kernel32.RemoveDirectory(dirPath) && exception == null)
    exception = mountPointException ?? Win32Marshal.GetExceptionForWin32Error(errorCode, fileName);

変更内容

  • FileSystem.Windows.cs (+14/-4行):RemoveDirectoryRecursiveメソッドのエラーハンドリング改善。DeleteVolumeMountPointエラーを共有のexceptionに直接代入せず、mountPointExceptionに段階化し、RemoveDirectoryも失敗した場合のみ昇格させるように修正

  • Delete.Windows.cs (+77行):テスト追加

    • RecursiveDelete_DirectoryContainingJunction:親ディレクトリにジャンクションを含む構造を作成し、Directory.Delete(parent, true)実行後、親とジャンクションが削除され、ジャンクション先のファイルは無傷であることを検証
    • Delete_Junction:ジャンクション直接指定時の削除テスト
    • Delete_VolumeMountPoint:ボリュームマウントポイント直接指定時の削除テスト(昇格権限とNTFS要件あり)

パフォーマンスへの影響

影響なし。エラーハンドリング ロジックの改善であり、実行パスやパフォーマンス特性の変更はありません。

関連Issue

  • Issue #86249(元々のジャンクション削除失敗の報告)
  • PR #124830

その他

  • 互換性:破壊的変更なし。正常な動作への修正であり、既存の成功ケースに影響なし
  • プラットフォーム:Windows固有の修正。シンボリックリンクは既に正常に動作していたため、ジャンクション固有の問題
  • テスト戦略:非管理者実行時と管理者実行時の両方のエラーケースをカバーする堅牢なテスト設計

#124798 JIT: Refactor async-to-sync call optimization

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月24日 16:19:08(UTC)
  • マージ日時: 2026年02月28日 06:58:00(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT コンパイラの非同期呼び出し最適化をリファクタリングしました。新しい getAsyncOtherVariant JIT-EE API を導入して、async/task-returning メソッドの別の非同期バリアントを返せるようにしました。従来の AwaitVirtual トークンを削除し、JIT 側で直接呼び出しの場合に最適化を実装することで、VM とのインターフェースを簡潔化しています。

変更内容

  • corinfo.h: getAsyncOtherVariant API を新規追加
  • JIT コンパイラ: importer.cpp と importercalls.cpp で非同期呼び出し最適化ロジックを実装
  • VM インターフェース: jitinterface.cpp で新しい API の実装、AwaitVirtual トークン削除
  • プロジェクト修正: ilc.slnx と crossgen2.slnx を VS からのコンパイルに対応
  • テスト: async EH テストをインタープリタで実行する際のマーキング追加(#124044 対応)
  • ジェネレータツール: superpmi と crossgen2/ilc の jitinterface ヘッダーを更新
  • C# ツール: CorInfoImpl.cs のマネージド JIT インターフェース実装を更新

パフォーマンスへの影響

VM と JIT の間での最適化制御ロジックを JIT 側に移行することで、呼び出し関連のシリアライゼーション/デシリアライゼーション処理が削減される可能性があります。具体的なベンチマーク値は提供されていません。

関連Issue

  • #124545(修正対象)
  • #124044(async EH テスト対応)

その他

このリファクタリングは互換性を伴う変更(JIT-EE API の変更)のため、jiteeversionguid.h でバージョン GUID が更新されています。


#124725 Fix operator precedence bug in SystemNative_FSync causing silent fsync errors on macOS SMB shares

  • 作成者: @Copilot
  • 作成日時: 2026年02月22日 12:53:45(UTC)
  • マージ日時: 2026年02月28日 20:29:31(UTC)
  • ラベル: area-System.IO

概要

macOSのSystemNative_FSync関数に存在するC演算子優先度バグを修正しました。バグによりfcntl(fd, F_FULLFSYNC)のエラーが暗黙に無視され、SMBネットワーク共有上でファイルが破損・切り詰められる問題を解決します。FileStream.Flush(flushToDisk: true)を使用するデータベースやトランザクションログなどに影響します。

// 修正前(バグ): result が boolean値(0または1)を取得
// while ((result = fcntl(fileDescriptor, F_FULLFSYNC) < 0) && errno == EINTR);

// 修正後(正常): result が実際の戻り値(エラー時は-1)を取得
// while ((result = fcntl(fileDescriptor, F_FULLFSYNC)) < 0 && errno == EINTR);

変更内容

  • src/native/libs/System.Native/pal_io.c:

    • EINTR再試行ループの閉じ括弧位置を修正(< 0の前に移動)
    • fcntl(F_FULLFSYNC)失敗時にfsyncへのフォールバック機能を追加
    • #ifガード簡略化(HAVE_F_FULLFSYNCチェック削除)
  • src/native/libs/configure.cmake: F_FULLFSYNCシンボル検出ロジック削除

  • src/native/libs/Common/pal_config.h.in: HAVE_F_FULLFSYNC定義削除

パフォーマンスへの影響

影響なし。修正は既存の予期された動作の復元であり、フォールバック機構(SQLiteやChromiumと同じパターン)はエラー処理パスでのみ動作します。正常系パフォーマンスに変化なし。

関連Issue

なし

その他

  • 重要度: 高い。データ破損につながる既知バグの修正
  • リスク: 最小限。1文字の括弧変更で意図された動作を復元
  • 互換性: API表面に変更なし
  • 他の全てのEINTR再試行ループ(FLock、ChDir、ChModなど)の監査完了。本バグはSystemNative_FSyncのみで発生

#124670 Move diagnostics out of DownlevelLibraryImportGenerator into a separate analyzer

  • 作成者: @Copilot
  • 作成日時: 2026年02月20日 19:56:15(UTC)
  • マージ日時: 2026年02月28日 04:02:36(UTC)
  • ラベル: area-CodeGen-coreclr

概要

このPRは、DownlevelLibraryImportGeneratorから診断ロジックを専用アナライザーDownlevelLibraryImportDiagnosticsAnalyzerへ分離する設計変更です。これはPR #123780でLibraryImportGeneratorに対して実施された変更を同じパターンで適用するもので、Roslynの推奨事項に従い、ジェネレータはコード生成に集中し、診断はアナライザが責務を持つアーキテクチャへの移行です。

変更内容

  • 新規ファイル: DownlevelLibraryImportDiagnosticsAnalyzer.cs (304行)

    • 無効なメソッドシグネチャ検証、非サポート型マーシャリング、LCIDConversion非対応、InvalidStringMarshallingConfigurationCannotForwardToDllImport(非Utf16StringMarshalling)、RequiresAllowUnsafeBlocksの診断ロジックを実装
    • GetDiagnosticIfInvalidMethodForGenerationをジェネレータ用に公開
  • 変更ファイル: DownlevelLibraryImportGenerator.cs

    • IncrementalStubGenerationContextからDiagnosticsフィールドを削除
    • パイプラインが直接MemberDeclarationSyntaxを返すように簡素化(タプル廃止)
    • 診断報告ロジックを削除し、アナライザ経由で検証
  • 削除ファイル: Comparers.cs (70行)

    • タプル比較が不要になったため削除
  • テスト更新: Diagnostics.csStringMarshallingForwardingNotSupported_ReportsDiagnosticをアナライザ対応に更新

パフォーマンスへの影響

影響なし

  • 診断重複排除の最適化:RequiresAllowUnsafeBlocksAllowUnsafeが偽の場合のみ登録し、不要なコールバック呼び出しを回避
  • パイプラインの簡素化(タプル廃止)により若干メモリ削減の可能性

関連Issue

PR #123780(LibraryImportGeneratorの同様の設計変更)を参照しています

その他

この変更は破壊的変更ではなく内部実装の整理です。公開APIは変わらず、診断の報告内容も同等に保持されます。ジェネレータとアナライザの責務分離により、将来的なメンテナンス性が向上します。


目次