Blocco di Garbage Collection nell'API di analisi

Aggiornamento: novembre 2007

Quando Common Language Runtime chiama determinati metodi nell'interfaccia ICorProfilerCallback, il runtime può eseguire il Garbage Collection solo in seguito alla restituzione da parte del profiler del controllo dalla chiamata in questione. Ciò accade perché i servizi di analisi non possono creare sempre lo stack in uno stato sicuro per un Garbage Collection. Al contrario, il Garbage Collection viene disabilitato intorno a quel callback. In questi casi, il profiler deve restituire il controllo prima possibile. Questa situazione si applica ai callback indicati di seguito:

• 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

Inoltre i callback indicati di seguito consentono al profiler di bloccare il Garbage Collection per singola chiamata, utilizzando il parametro fIsSafeToBlock:

• ICorProfilerCallback::JITCompilationStarted

• ICorProfilerCallback::JITCompilationFinished

Notare che l'eventuale blocco del profiler causa il ritardo del Garbage Collection. Tale ritardo non crea problemi purché il profiler non chiami una funzione CLR che attiva un Garbage Collection o alloca spazio nell'heap gestito.

Vedere anche

Concetti

Garbage Collection nell'API di analisi

Altre risorse

Funzionalità comuni nell'API di analisi

Cenni preliminari sull'analisi