L'obtention de racines globales des programmes .NET

Question

J'ai récemment commencé à utiliser les outils de profilage ANTS pour le travail de production. En plus d'être surpris par leur awesomeness, je ne pouvais pas aider à se demander comment ils fonctionnent. Par exemple, l'un des plus fort utiles qui vous permet de visualiser les racines globales d'un programme complet en cours d'exécution avec le nombre de références à des valeurs de différents types.

Comment cet outil se procurer cette information?

Answer 1

(divulgation complète: Je suis sur l'équipe Profiler Visual Studio, mais l'information ci-dessous est public)

Vous pouvez le faire en écrivant un profileur CLR qui fonctionne à l'intérieur du processus que vous ciblez. profileurs CLR sont C ++ objets COM qui s'instanciés par le moteur d'exécution lorsque les variables d'environnement et de COR_PROFILER COR_PROFILING_ENABLED sont définies (voir ici ). Il y a deux principaux CLR profilage interfaces , en particulier, ICorProfilerCallback et ICorProfilerInfo . ICorProfilerCallback est ce que les utilisations CLR pour vous informer sur les événements spécifiques que vous vous abonnez à (module charge, fonction JIT compliation, création de fil, événements GC), tandis que ICorProfilerInfo peut être utilisé par votre profileur pour obtenir des informations supplémentaires sur les threads, les modules, les types, les méthodes et les métadonnées pour les ensembles de chargement. Cette interface est ce que vous peut utiliser pour obtenir des informations de symbole sur les types attribués.

Avec votre profileur en cours, vous pouvez forcer un GC à travers ICorProfilerInfo::ForceGC . Après les finalise GC, votre profileur sera averti via ICorProfilerCallback2::GarbageCollectionFinished , et vous obtiendrez les références des racines par ICorProfilerCallback2::RootReferences2 . Lorsque vous combinez les informations de référence racine avec ICorProfilerCallback::ObjectReferences , vous pouvez obtenir le graphe complet de référence d'objet pour votre application .NET.

Vous pouvez obtenir plus d'informations en temps réel en utilisant le ICorProfilerCallback::ObjectAllocated rappel pour déterminer si des objets CLR individuels sont créées. Cela peut être coûteux, mais, puisque vous engager au moins un appel de fonction supplémentaire pour chaque objet alloué. Vous pouvez suivre les objets individuels en cartographiant le CLR ObjectID attribué à votre propre ID interne. Un ObjectID pour un objet donné est un pointeur éphémère car il peut changer le ramassage des ordures se produisent, ce qui peut provoquer des objets à déplacer pendant le compactage. Ce processus est illustré ici . Vous pouvez utiliser les informations de ICorProfilerCallback::MovedReferences pour suivre des objets en mouvement.

Pour activer les callbacks mentionnés ci-dessus, vous devez dire à l'API de profilage CLR que vous êtes intéressé à eux. Vous pouvez le faire en spécifiant COR_PRF_MONITOR_GC et COR_PRF_MONITOR_OBJECT_ALLOCATED dans le cadre de vos drapeaux d'événement lorsque vous appelez ICorProfilingInfo::SetEventMask .

David Broman est le développeur sur le profileur CLR et son blog a tonnes d'informations sur le profilage en général, y compris tous les pièges fous et les problèmes que vous pourriez rencontrer.

Answer 2

Profilers comme ANTS utiliser une « API de profilage » présenté par le CLR lui-même, qui peut tout simplement vous dire ce qui se passe à l'intérieur du CLR. Par exemple, il est un rappel méthode API qui se produisent lorsqu'un objet est attribué, porte bien son nom ObjectAllocated () . De même, il y a des événements pour lorsque les méthodes sont entrées, lorsque les threads sont créés, etc etc.

L'API de profilage d'origine est appelé ICorProfilerCallback. Les versions ultérieures sont appelées CoreProfilerCallback2 et CoreProfilerCallback3. Si vous google ces noms, vous trouverez exactement les réponses que vous recherchez. Sur CodeProject vous pouvez voir un exemple pratique: Création d'un Profiler .NET personnalisée

Une note finale: L'API ne peut pas être utilisé à partir du code managé comme C # et VB.NET. Il est uniquement disponible à partir du code non géré comme par exemple C ou C ++. Ainsi, une application C # ne peut pas utiliser cette API pour examiner son propre comportement et les objets, par exemple.