.net フレームワーク プロファイラーで疑問に思っていたのですが、ExceptionThrown ( https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/icorprofilercallback-exceptionthrown-method ) は GC とオーバーラップしないことが保証されていますか?
ドキュメントを見ると、「プロファイラーがここでブロックし、ガベージ コレクションが試行されると、このコールバックが戻るまでランタイムがブロックされます」と表示されます。
ただし、paint.net ( https://www.getpaint.net/ - バージョン 4.1.6) に接続されているプロファイラーを実行したところ、ExceptionThrown 中に GC を取得した特定のケースが見られました。（しかし、それは非常にまれでした-起動時にのみ発生し、約20回の実行ごとに1回だけ発生しました）-gcがデータを移動したため、読み取り中にデータが正しく変更されました。
少なくとも .net コア バージョン ( https://github.com/dotnet/coreclr/blob/master/Documentation/botr/profiling.md)では、どのコールバックが GC コールアウト セーフであるかが明示的に示されています。ExceptionThrown はその 1 つではありません。ExceptionUnwindFunctionEnter は、たとえばです。ただし、.NET フレームワークに戻る - https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/icorprofilercallback-exceptionunwindfunctionenter-method - .NET フレームワークのドキュメントでは、GC に関するコメントはそれと同じですExceptionThrown の。
私は、.NET コア != .NET フレームワークを知っています。ただし、プロファイラーのコードは非常に似ており、同じ保証があるように感じます。.NET フレームワークのコールバックに関する GC の安全性に関する同様のリソースは見つかりませんでした。
このすべてのイントロの後、私の質問は次のとおりです。
.NET フレームワーク clr プロファイラー ExceptionThrown コールバックは GC セーフである必要があります。もしそうなら、GC 呼び出しが ExceptionThrown 中に開始および終了するのを見たのはどうしてでしょうか (clr の潜在的なバグまたは予想される動作)?
バグではない場合、core-clr に関する同様のドキュメントに基づいて、.NET フレームワーク clr プロファイラー UnwindExceptionFunctionEnter コールバックが GC セーフであることに少なくとも 100% 依存できますか?
どうも