Garbage collection bloquée dans l'API de profilage

Mise à jour : novembre 2007

Lorsque le Common Language Runtime (CLR) appelle certaines méthodes dans l'interface ICorProfilerCallback, le runtime ne peut pas exécuter de garbage collection tant que le profileur n'a pas retourné le contrôle à partir de cet appel. C'est parce que les services de profilage ne peuvent pas toujours construire la pile dans un état qui est sûr pour un garbage collection. À la place, le garbage collection est désactivé au moment de ce rappel. Dans ces cas, le profileur doit retourner le contrôle dès que possible. Cette situation s'applique aux rappels suivants :

• 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

De plus, les rappels suivants permettent au profileur de bloquer le garbage collection, appel par appel, en utilisant le paramètre fIsSafeToBlock :

• ICorProfilerCallback::JITCompilationStarted

• ICorProfilerCallback::JITCompilationFinished

Notez que si le profileur bloque, il différera le garbage collection. Ce délai est sans conséquence tant que le profileur n'appelle pas une fonction CLR que déclenche un garbage collection ou alloue l'espace dans le tas managé.

Voir aussi

Concepts

Garbage collection dans l'API de profilage

Autres ressources

Fonctions communes dans l'API de profilage

Vue d'ensemble du profilage