Garbage collection dans l'API de profilage
Les profileurs peuvent recevoir des notifications de garbage collection.
Lorsque l'utilisateur spécifie l'indicateur COR_PRF_MONITOR_GC, tous les événements de garbage collection sont déclenchés dans le profileur, à l'exception des événements ICorProfilerCallback::ObjectAllocated. Les événements ObjectAllocated sont explicitement contrôlés par l'indicateur COR_PRF_MONITOR_OBJECT_ALLOCATED pour des raisons de performance. Notez que lorsque l'indicateur COR_PRF_MONITOR_GC est activé, le garbage collection simultané est désactivé.
Dans les versions 1.0 et 1.1 du .NET Framework, le profileur de code détermine si le garbage collection est en cours en surveillant les rappels ICorProfilerCallback::RuntimeSuspendFinished et ICorProfilerCallback::RuntimeResumeStarted lorsque la raison de l'interruption est COR_PRF_SUSPEND_FOR_GC. Pendant l'arrêt, le Common Language Runtime (CLR) s'interrompt également et un ou plusieurs garbage collections peuvent avoir lieu sans que le profileur de code n'en soit notifié, car l'état du runtime est déjà interrompu. La fin du garbage collection n'est pas facile à détecter dans ces circonstances. Le profileur de code doit détecter le tout premier rappel ObjectAllocated qui a eu lieu après un rappel ICorProfilerCallback::ObjectReferences ou ICorProfilerCallback::RootReferences.
Dans la version 2.0 du .NET Framework et les versions ultérieures, le profileur de code peut utiliser les rappels ICorProfilerCallback2::GarbageCollectionStarted et ICorProfilerCallback2::GarbageCollectionFinished pour déterminer si le garbage collection est en cours et identifier les générations couvertes. (Pour plus d'informations sur les générations de garbage collection, consultez l'énumération COR_PRF_GC_GENERATION.) Ces rappels ne sont pas concernés par le problème d'arrêt mentionné dans la section précédente.
.gif "Remarque") Remarque |
|---|
Le garbage collection simultané n'est pas pris en charge dans les applications exécutant l'émulateur WOW64 x86 sur les systèmes 64 bits qui implémentent l'architecture Intel Itanium (anciennement appelée IA-64).Pour plus d'informations sur l'utilisation de WOW64 sur les systèmes Windows 64 bits, consultez Exécution d'applications 32 bits (en anglais). |
Blocage de garbage collection
Lorsque le Common Language Runtime 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 :
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 :
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é.