Garbage Collection in the Profiling API
Profilers can receive garbage collection notifications.
When the user specifies the COR_PRF_MONITOR_GC flag, all garbage collection events except for ICorProfilerCallback::ObjectAllocated events will be raised in the profiler. ObjectAllocated events are explicitly controlled by the COR_PRF_MONITOR_OBJECT_ALLOCATED flag for performance reasons. Note that when the COR_PRF_MONITOR_GC flag is enabled, concurrent garbage collection is turned off.
In the .NET Framework version 1.0 and 1.1, the code profiler determines that garbage collection is taking place by monitoring the ICorProfilerCallback::RuntimeSuspendFinished and ICorProfilerCallback::RuntimeResumeStarted callbacks when the suspension reason is COR_PRF_SUSPEND_FOR_GC. During shutdown, the common language runtime (CLR) also gets suspended, and one or more garbage collections may take place without the code profiler being notified, because the runtime is already in a suspended state. Detecting the completion of garbage collection in those circumstances is not trivial. The code profiler has to detect the very first ObjectAllocated callback that took place after an ICorProfilerCallback::ObjectReferences or ICorProfilerCallback::RootReferences callback.
In the .NET Framework version 2.0 and later, the code profiler may use the ICorProfilerCallback2::GarbageCollectionStarted and ICorProfilerCallback2::GarbageCollectionFinished callbacks to determine that garbage collection is taking place, and to identify which generations are covered. (For more information about garbage-collection generations, see the COR_PRF_GC_GENERATION enumeration.) These callbacks do not have the shutdown issue mentioned in the previous section.
Note
Concurrent garbage collection is not supported in applications running the WOW64 x86 emulator on 64-bit systems that implement the Intel Itanium architecture (formerly called IA-64). For more information about using WOW64 on 64-bit Windows systems, see Running 32-bit Applications.
Garbage Collection Blocking
When the common language runtime calls certain methods in the ICorProfilerCallback interface, the runtime cannot perform a garbage collection until the profiler returns control from that call. This is because profiling services cannot always construct the stack into a state that is safe for a garbage collection. Instead, garbage collection is disabled around that callback. In these cases, the profiler should return control as soon as possible. This situation applies to the following callbacks:
ICorProfilerCallback::ExceptionOSHandlerEnter, ICorProfilerCallback::ExceptionOSHandlerLeave
ICorProfilerCallback::ExceptionUnwindFunctionEnter, ICorProfilerCallback::ExceptionUnwindFunctionLeave
ICorProfilerCallback::ExceptionUnwindFinallyEnter, ICorProfilerCallback::ExceptionUnwindFinallyLeave
ICorProfilerCallback::ExceptionCatcherEnter, ICorProfilerCallback::ExceptionCatcherLeave
ICorProfilerCallback::ExceptionCLRCatcherFound, ICorProfilerCallback::ExceptionCLRCatcherExecute
ICorProfilerCallback::COMClassicVTableCreated, ICorProfilerCallback::COMClassicVTableDestroyed
In addition, the following callbacks allow the profiler to block garbage collection, call by call, by using the fIsSafeToBlock parameter:
Note that if the profiler does block, it will delay garbage collection. This delay is harmless as long as the profiler does not call a CLR function that triggers a garbage collection or allocates space in the managed heap.