Garbage Collection in der Profilerstellungs-API
Profiler können Garbage Collection-Benachrichtigungen empfangen.
Wenn der Benutzer das COR_PRF_MONITOR_GC-Flag angibt, werden alle Garbage Collection-Ereignisse außer ICorProfilerCallback::ObjectAllocated-Ereignissen im Profiler ausgelöst. ObjectAllocated-Ereignisse werden aus Leistungsgründen explizit durch das COR_PRF_MONITOR_OBJECT_ALLOCATED-Flag gesteuert. Beachten Sie, dass bei aktiviertem Flag COR_PRF_MONITOR_GC die gleichzeitige Garbage Collection deaktiviert ist.
In .NET Framework, Version 1.0 und 1.1, ermittelt der Codeprofiler, ob eine Garbage Collection stattfindet, indem er den ICorProfilerCallback::RuntimeSuspendFinished-Rückruf und den ICorProfilerCallback::RuntimeResumeStarted-Rückruf überwacht, wenn der Grund für die Unterbrechung COR_PRF_SUSPEND_FOR_GC ist. Während des Herunterfahrens wird auch die Common Language Runtime (CLR) unterbrochen, und eine oder mehrere Garbage Collections können stattfinden, ohne dass der Codeprofile benachrichtigt wird, da die Laufzeit bereits im unterbrochenen Zustand ist. Es ist recht schwierig, unter diesen Umständen die Beendigung der Garbage Collection zu ermitteln. Der Codeprofiler muss den allerersten ObjectAllocated-Rückruf erkennen, der nach einem ICorProfilerCallback::ObjectReferences-Rückruf oder einem ICorProfilerCallback::RootReferences-Rückruf stattgefunden hat.
In .NET Framework, ab Version 2.0, verwendet der Codeprofiler möglicherweise die ICorProfilerCallback2::GarbageCollectionStarted- und ICorProfilerCallback2::GarbageCollectionFinished-Rückrufe, um zu bestimmen, dass eine Garbage Collection stattfindet, und um die behandelten Generationen zu identifizieren. (Weitere Informationen über Garbage Collection-Generationen finden Sie unter COR_PRF_GC_GENERATION-Enumeration.) Bei diesen Rückrufen tritt nicht das im vorherigen Abschnitt erwähnte Problem mit dem Herunterfahren auf.
.gif "Hinweis") Hinweis |
|---|
Die gleichzeitige Garbage Collection wird nicht in Anwendungen unterstützt, die den WOW64 x86-Emulator auf 64-Bit-Systemen mit einer Implementierung der Intel Itanium-Architektur (früher als IA-64 bezeichnet) ausführen.Weitere Informationen zur Verwendung von WOW64 auf 64-Bit-Windows-Systemen finden Sie unter Ausführen von 32-Bit-Anwendungen. |
Blockieren der Garbage Collection
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.