ID de profilage et de notification d'exécution
Les notifications d'exécution fournissent un ID aux éléments signalés (classes, threads, domaines d'application, etc.). Ces ID permettent d'interroger le Common Language Runtime (CLR) pour obtenir davantage d'informations. Chaque ID correspond à l'adresse d'un bloc en mémoire qui décrit l'élément. Toutefois, les ID doivent être traités en tant que handles opaques par les profileurs. Si un ID non valide est utilisé dans un appel à une fonction de profilage, les résultats ne sont alors pas définis. Il en résultera très probablement une violation d'accès. Le profileur doit garantir que les ID qui sont utilisés sont valides. L'API de profilage n'exécute pas tous les types de validation, car cela générerait des charges mémoire et ralentirait considérablement l'exécution de l'application.
Les sections suivantes décrivent les caractéristiques des ID figurant dans l'API de profilage.
Unicité
Un ProcessID est unique à l'échelle du système pendant la durée de vie du processus. Tous les autres ID sont uniques à l'échelle du processus pendant la durée de vie de l'ID.
Hiérarchie et relation contenant-contenu
Les ID sont réorganisés selon une hiérarchie qui reflète la hiérarchie du processus. Les processus contiennent des domaines d'application, qui contiennent des assemblys, qui contiennent des modules, qui contiennent des classes, qui contiennent des fonctions. Les threads sont contenus dans des processus et peuvent se déplacer d'un domaine d'application à un autre. Les objets sont essentiellement contenus dans des domaines d'application et un nombre très limité d'objets peuvent être simultanément membres de plusieurs domaines d'application. Les contextes sont contenus dans des processus.
Durée de vie et stabilité
Lorsqu'un processus, un domaine d'application, un assembly, un thread ou un objet donné est détruit ou libéré ou prend fin, l'ID qui y est associé devient non valide. Lorsqu'un ID donné devient non valide, tous les ID qu'il contient deviennent également non valides. Par exemple, lorsqu'un domaine d'application est déchargé, son AppDomainID devient non valide. Les AssemblyID, ModuleID, ClassID et FunctionID qui correspondent aux assemblys, modules, classes et fonctions contenus dans le domaine d'application deviennent également simultanément non valides.
La durée de vie et la stabilité d'ID spécifiques sont les suivantes :
ProcessID : actif et stable de l'appel à la méthode ICorProfilerCallback::Initialize jusqu'au retour de la méthode ICorProfilerCallback::Shutdown.
AppDomainID : actif et stable de l'appel à la méthode ICorProfilerCallback::AppDomainCreationFinished jusqu'au retour de la méthode ICorProfilerCallback::AppDomainShutdownStarted.
AssemblyID, ModuleID, ClassID : actifs et stables de l'appel à la méthode LoadFinished pour l'ID jusqu'au retour de la méthode UnloadStarted pour l'ID.
FunctionID : actif et stable de l'appel à la méthode ICorProfilerCallback::JITCompilationFinished ou ICorProfilerCallback::JITCachedFunctionSearchFinished jusqu'à la destruction du ClassID contenant.
ThreadID : actif et stable de l'appel à la méthode ICorProfilerCallback::ThreadCreated jusqu'au retour de la méthode ICorProfilerCallback::ThreadDestroyed.
ObjectID : actif à partir de l'appel à la méthode ICorProfilerCallback::ObjectAllocated. Est susceptible d'être modifié ou supprimé à chaque garbage collection.
GCHandleID : actif de l'appel à la méthode ICorProfilerCallback2::HandleCreated jusqu'au retour de la méthode ICorProfilerCallback2::HandleDestroyed.
De plus, tout ID retourné par une fonction de profilage est activé au même moment qu'il est retourné.
Affinité de domaine d'application
Chaque domaine d'application créé par utilisateur dans un processus a un AppDomainID. Le domaine par défaut, ainsi qu'un pseudodomaine spécial qui permet de maintenir des assemblys indépendants du domaine, ont également des AppDomainID.
Les assemblys, les modules, les classes, les fonctions et les handles de garbage collector ont une affinité de domaine d'application. En d'autres termes, si un assembly est chargé dans plusieurs domaines d'application, l'assembly et tous ses modules, classes, fonctions et handles de garbage collector auront alors un ID différent dans chaque domaine d'application et les opérations sur chaque ID seront uniquement appliquées au domaine d'application qui y est associé. Les assemblys indépendants du domaine apparaissent dans le pseudodomaine spécial mentionné plus haut.
Remarques supplémentaires
Tous les ID, sauf ObjectID, doivent être traités comme des valeurs opaques. La plupart des ID sont plutôt explicites. Les ID suivants méritent une explication détaillée :
Les ClassID représentent des classes. Dans le cadre de classes génériques, ils représentent des types pleinement instanciés. List<int>, List<char>, List<object> et List<string> ont chacun leur propre ClassID. List<T> est un type non instancié qui n'a aucun ClassID. Dictionary<string,V> est un type partiellement instancié qui n'a aucun ClassID.
Les FunctionID représentent le code natif d'une fonction. Dans le cadre de fonctions génériques (ou de fonctions sur des classes génériques), plusieurs instanciations de code natif et, par conséquent, plusieurs FunctionID, peuvent exister pour une fonction donnée. Comme les instanciations de code natif peuvent être partagées entre différents types (par exemple, List<string> et List<object> partagent du code), un FunctionID peut appartenir à plusieurs ClassID.
Les ObjectID représentent des objets récupérés par le garbage collector. Un ObjectID correspond à l'adresse actuelle d'un objet au moment où le profileur reçoit l'ObjectIDet peut changer à chaque garbage collection. Par conséquent, une valeur ObjectID n'est valide qu'entre le moment où elle est reçue et le moment où le garbage collection suivant commence. Le CLR fournit également des notifications à un profileur pour qu'il mette à jour ses tables de suivi d'objet internes et puisse maintenir un ObjectID valide pendant les garbage collections.
Les GCHandleID représentent des entrées de la table de handles du garbage collection. Les GCHandleID sont, contrairement aux ObjectID, des valeurs opaques. Les handles de garbage collection sont créés par le CLR lui-même dans certains cas. Ils peuvent également être créés à l'aide de la structure GCHandle. (Notez que la structure GCHandle ne représente que le handle ; le handle n'est pas contenu dans la structure.)
Les ThreadID représentent des threads managés. Si un hôte prend en charge une exécution en mode fibre, un thread managé peut alors exister sur différents threads de système d'exploitation, selon le moment auquel il est examiné.
.gif "Remarque")
RemarqueLe profilage d'applications en mode fibre n'est pas pris en charge dans la version 2 du .NET Framework.