Garbage Collection Blocking in the Profiling API

When the common language runtime (CLR) 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:

• FunctionEnter, FunctionLeave, FunctionTailcall

• 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:

• ICorProfilerCallback::JITCompilationStarted

• ICorProfilerCallback::JITCompilationFinished

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.

See Also

Concepts

Garbage Collection in the Profiling API

Common Features in the Profiling API

Profiling Overview