ネットコア 2.2 で、Gen2 の同時 GC がバックグラウンド GC スレッドで実行されていないように見える問題が時折発生し、代わりにコレクションをトリガーしたスレッドで実行されているようです。
これは、デフォルトの GC プロファイル (ワークステーション、同時 GC が有効、インタラクティブな待機時間モード) を使用して 64 ビット .NET Core 2.2 ランタイムのリリース構成でアプリを実行している Windows 10 開発で観察され、perfview サンプルを取得できました。発生の:
GC ソースに目を通すと、このコミットで問題が発生している可能性があります。 変更前は、 bgc_thread
はスレッド作成時に設定され、 void gc_heap::garbage_collect (int n)
チェックされるまでに設定されることが保証されていました。 変更後、 bgc_thread
は実行開始時に新しいスレッド内に設定されるようになりました。これにより、競合状態が発生し、同時 GC が続行するのに間に合うようにフィールドが設定されない可能性があるようです。
あ、いい発見!
@PeterSolMS 、 @VSadov のいずれかを見て、修正して
ここで行われた実際の GC はもはや BGC ではないということを指摘したかっただけです.BGC スレッドの作成に失敗したものとして扱うだけなので、単純に完全なブロッキング GC を行っています。 イベントは誤解を招くものである (まだバックグラウンドと表示されている) ため、実際に BGC を実行できなかった (BGC スレッドの作成に失敗したなどの理由で) 場合に備えて、これも修正する必要があります。
bgc_thread を設定するレースでは、実際にはbgc_thread_stub
、この行の後のCreateSuspendableThread
に設定する必要はありません。
args.Thread = SetupUnstartedThread(FALSE);
Thread オブジェクトはすでに使用可能です - この関数の後のすべてのロジックは、とにかく作成された Thread を変更しません。
最も参考になるコメント
ここで行われた実際の GC はもはや BGC ではないということを指摘したかっただけです.BGC スレッドの作成に失敗したものとして扱うだけなので、単純に完全なブロッキング GC を行っています。 イベントは誤解を招くものである (まだバックグラウンドと表示されている) ため、実際に BGC を実行できなかった (BGC スレッドの作成に失敗したなどの理由で) 場合に備えて、これも修正する必要があります。