Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Aktualisiert: November 2007
Wenn die Common Language Runtime (CLR) bestimmte Methoden in der ICorProfilerCallback-Schnittstelle aufruft, kann die CLR erst dann eine Garbage Collection durchführen, wenn der Profiler die Steuerung von diesem Aufruf zurückgibt. Dies liegt daran, dass Profilerstellungsdienste den Stapel nicht immer in einen Zustand konstruieren können, in dem gefahrlos eine Garbage Collection durchgeführt werden kann. Stattdessen wird die Garbage Collection um diesen Rückruf deaktiviert. In diesen Fällen sollte der Profiler die Steuerung so schnell wie möglich zurückgeben. Diese Situation gilt für die folgenden Rückrufe:
ICorProfilerCallback::ExceptionOSHandlerEnter, ICorProfilerCallback::ExceptionOSHandlerLeave
ICorProfilerCallback::ExceptionUnwindFunctionEnter, ICorProfilerCallback::ExceptionUnwindFunctionLeave
ICorProfilerCallback::ExceptionUnwindFinallyEnter, ICorProfilerCallback::ExceptionUnwindFinallyLeave
ICorProfilerCallback::ExceptionCatcherEnter, ICorProfilerCallback::ExceptionCatcherLeave
ICorProfilerCallback::ExceptionCLRCatcherFound, ICorProfilerCallback::ExceptionCLRCatcherExecute
ICorProfilerCallback::COMClassicVTableCreated, ICorProfilerCallback::COMClassicVTableDestroyed
Darüber hinaus ermöglichen die folgenden Rückrufe dem Profiler, die Garbage Collection unter Verwendung des fIsSafeToBlock-Parameters für einzelne Aufrufe zu blockieren:
Beachten Sie, dass eine Blockierung des Profilers die Garbage Collection verzögert. Diese Verzögerung ist harmlos, solange der Profiler keine CLR-Funktion aufruft, die eine Garbage Collection auslöst, oder Speicher im verwalteten Heap reserviert.
Siehe auch
Konzepte
Garbage Collection in der Profilerstellungs-API