Profilage dans le .NET Framework 2.0
L'API de profilage a été améliorée dans .NET Framework version 2.0 pour fournir des fonctions supplémentaires. Les nouvelles fonctionnalités sont exposées via deux nouvelles interfaces : ICorProfilerCallback2 et ICorProfilerInfo2.
Une DLL de profileur qui a été écrite pour .NET Framework version 1.0 ou 1.1 ne fonctionnera pas correctement dans l'environnement du Common Language Runtime (CLR) .NET Framework 2.0. Pour mettre à jour votre DLL de profileur avec la version 2.0 ou ultérieure, vous devez implémenter l'interface ICorProfilerCallback2. L'interface ICorProfilerInfo2 hérite de l'interface ICorProfilerInfo et introduit de nouvelles méthodes qui prennent en charge l'interaction améliorée avec le CLR.
Les modifications sont décrites dans les sections suivantes :
Génériques
Fractionnement de code
Suppression de débogage en cours de processus
Rappels avec l'outil Native Image Generator (Ngen.exe)
Rappels de garbage collection améliorés
Objets figés
Diverses modifications d'API
En plus des modifications de l'API, un nouveau HRESULT, CORPROF_E_UNSUPPORTED_CALL_SEQUENCE a été ajouté. Pour plus d'informations sur les scénarios dans lesquels ce HRESULT peut être retourné, consultez CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Génériques
L'introduction de génériques dans le runtime a entraîné trois modifications dans l'API de profilage :
Un mappage univoque n'existe plus entre jetons typedef et valeurs ClassID, ou entre jetons MethodDef et valeurs FunctionID. Cela tient au fait que chaque classe ou fonction peut être instanciée pour plusieurs types différents. Les auteurs de profileur doivent lire ID de profilage et de notification d'exécution, examiner comment ils utilisent les méthodes ICorProfilerInfo::GetClassFromToken et ICorProfilerInfo::GetFunctionFromToken dans leur code, et réécrire leur code de façon compatible avec les génériques. L'API de profilage fournit deux nouvelles méthodes, ICorProfilerInfo2::GetClassFromTokenAndTypeArgs et ICorProfilerInfo2::GetFunctionFromTokenAndTypeArgs, pour prendre en charge les génériques.
Un mappage direct n'existe plus entre un FunctionID et le ClassID qu'il contient. Les optimisations de partage de code peuvent permettre à des instanciations différentes d'un type générique de partager le code. Vous pouvez déterminer le ClassID d'un FunctionID uniquement lorsque vous les examinez dans le contexte d'une activation particulière de la fonction.
Les méthodes d'informations sur les classes et les fonctions existant dans l'interface ICorProfilerInfo ne fournissent pas d'informations à propos des arguments de type pour les types génériques et les fonctions. Les méthodes ICorProfilerInfo2::GetClassIDInfo2 et ICorProfilerInfo2::GetFunctionInfo2 sont fournies dans ce but. Notez que ces méthodes ne peuvent pas toujours fournir cette information ; consultez ID de profilage et de notification d'exécution pour plus d'informations.
Retour au début
Fractionnement de code
Les assemblys dans le .NET Framework ont subi une optimisation des performances. Le code natif précompilé a été fractionné en plusieurs régions par fonction. Par conséquent, la méthode ICorProfilerInfo::GetCodeInfo existante ne peut plus décrire correctement l'étendue du code natif d'une fonction. Les profileurs doivent utiliser, à la place, la méthode ICorProfilerInfo2::GetCodeInfo2 plus générale.
Retour au début
Suppression de débogage en cours de processus
Dans .NET Framework 2.0, le débogage en cours de processus a été remplacé par un jeu de fonctionnalités qui sont cohérentes avec l'API de profilage. L'instantané de la pile (consultez la rubrique Vue d'ensemble du profilage) et la fonctionnalité d'inspection d'objets en sont le résultat.
Retour au début
Rappels avec l'outil Native Image Generator (Ngen.exe)
Les optimisations significatives dans l'outil Native Image Generator (Ngen.exe) ont déplacé encore plus de tâches de l'exécution vers la phase de génération d'images natives. Cela a conduit aux modifications suivantes dans le comportement de l'API de profilage :
Pour la plupart des fonctions, les rappels JITCachedFunctionSearch ne sont plus reçus dans les images natives. Un profileur a deux options, selon la manière dont il utilise les rappels :
Si le profileur utilise les rappels pour collecter des informations à propos d'une fonction, il peut basculer vers un schéma où les informations sont rassemblées uniquement à propos d'une fonction donnée lorsque cette fonction est rencontrée la première fois pendant l'exécution du programme.
Si le profileur utilise des rappels pour forcer la compilation juste-à-temps (JIT) d'une fonction pour les besoins de l'instrumentation, il peut utiliser à la place des images natives améliorées par le profileur. Pour plus d'informations, consultez Génération de code dans l'API de profilage.
Pour la plupart des types, les rappels ClassLoad ne sont plus reçus dans les images natives. Les profileurs doivent utiliser des techniques d'évaluation au moment de l'exécution (ou évaluation paresseuse) pour de telles classes. Les profileurs qui utilisent déjà des images natives améliorées par profileur n'ont pas à modifier leur comportement. Toutefois, un profileur ne doit adopter les images natives améliorées par profileur que s'il a besoin de ces images pour d'autres raisons, car les images natives améliorées par profileur sont très différentes des images courantes.
Retour au début
Rappels de garbage collection améliorés
Les rappels de garbage collection ont été améliorés de plusieurs façons. Les rappels notifient maintenant au profileur que les handles de garbage collection ont été créés ou détruits, fournissent des informations à propos de la mise en file d'attente d'objets à finaliser et utilisent la méthode Collect pour forcer un garbage collection. La méthode ICorProfilerCallback2::RootReferences2, qui est une extension d'ICorProfilerCallback::RootReferences, fournit des informations à propos du type de chaque racine. Enfin, la méthode ICorProfilerCallback2::SurvivingReferences signale la disposition d'objets dans le tas qui est provoqué par un garbage collection de non-compactage.
Retour au début
Objets figés
Les objets figés qui sont nouveaux dans .NET Framework 2.0 sont des objets constants qui sont initialisés au temps de la génération de l'image native et gravés dans l'image native. Les objets figés ne sont pas déplacés par le garbage collection, mais ils peuvent être référencés par les objets de garbage collection. La nouvelle méthode ICorProfilerInfo2::EnumModuleFrozenObjects permet aux profileurs d'énumérer des objets figés.
Retour au début
Diverses modifications d'API
Le .NET Framework 2.0 introduit également les modifications d'API suivantes :
La méthode ICorProfilerInfo::SetFunctionReJIT retourne maintenant E_NOIMPL. Dans les précédentes versions, l'appel de cette méthode provoquait un interblocage.
La nouvelle méthode ICorProfilerCallback2::ThreadNameChanged fournit une notification des modifications dans le nom du thread.
La nouvelle méthode ICorProfilerInfo2::GetThreadAppDomain accepte un ID de thread et retourne le domaine d'application dans lequel ce thread s'exécute.
Retour au début