Profilerstellung in .NET Framework 2.0
Die Profilerstellungs-API wurde in .NET Framework 2.0 um zusätzliche Funktionen erweitert. Die neue Funktionalität wird über zwei neue Schnittstellen verfügbar gemacht: ICorProfilerCallback2 und ICorProfilerInfo2.
Eine Profiler-DLL, die für .NET Framework, Version 1.0 oder 1.1, geschrieben wurde, funktioniert in der Common Language Runtime (CLR)-Umgebung von .NET Framework 2.0 nicht richtig. Um die Profiler-DLL für die Verwendung von Version 2.0 oder höher zu aktualisieren, müssen Sie die ICorProfilerCallback2-Schnittstelle implementieren. Die ICorProfilerInfo2-Schnittstelle erbt von der ICorProfilerInfo-Schnittstelle und führt neue Methoden ein, die eine erweiterte Interaktion mit der CLR unterstützen.
Die Änderungen werden in den folgenden Abschnitten beschrieben:
Generika
Codeaufteilung
Aufhebung des prozessinternen Debuggens
Rückrufe mit dem Native Image Generator
Verbesserte Garbage Collection-Rückrufe
Fixierte Objekte
Verschiedene API-Änderungen
Neben den API-Änderungen wurde ein neues HRESULT hinzugefügt: CORPROF_E_UNSUPPORTED_CALL_SEQUENCE. Informationen zu den Szenarien, in denen dieses HRESULT zurückgegeben werden kann, finden Sie unter CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Generika
Die Einführung von Generika in der Laufzeit hat drei Änderungen in der Profilerstellungs-API bewirkt:
Es gibt keine Eins-zu-Eins-Zuordnung zwischen typedef-Token und ClassID-Werten oder zwischen MethodDef-Token und FunctionID-Werten mehr. Das liegt daran, dass jede Klasse oder Funktion für verschiedene Typen instanziiert werden kann. Entwickler von Profilern sollten den Abschnitt Profilerstellungs- und Laufzeitbenachrichtigungs-IDs lesen, überprüfen, wie sie die ICorProfilerInfo::GetClassFromToken-Methode und die ICorProfilerInfo::GetFunctionFromToken-Methode in ihrem Code verwenden, und den Code generikafähig umschreiben. Die Profilerstellungs-API stellt zur Unterstützung von Generika zwei neue Methoden bereit: ICorProfilerInfo2::GetClassFromTokenAndTypeArgs und ICorProfilerInfo2::GetFunctionFromTokenAndTypeArgs.
Es gibt keine direkte Zuordnung zwischen einer FunctionID und der darin enthaltenen ClassID mehr. Optimierungen für die gemeinsame Verwendung von Code können verschiedene Instanziierungen eines generischen Typs zur Freigabe von Code ermöglichen. Sie können die ClassID einer FunctionID nur bestimmen, wenn Sie sie im Kontext einer bestimmten Aktivierung der Funktion überprüfen.
Die vorhandenen Methoden für Klassen- und Funktionsinformationen in der ICorProfilerInfo-Schnittstelle stellen keine Informationen über Typargumente für generische Typen und Funktionen bereit. Zu diesem Zweck wurden die ICorProfilerInfo2::GetClassIDInfo2-Methode und die ICorProfilerInfo2::GetFunctionInfo2-Methode bereitgestellt. Beachten Sie, dass diese Methoden die Informationen nicht immer bereitstellen können. Weitere Informationen finden Sie unter Profilerstellungs- und Laufzeitbenachrichtigungs-IDs.
Zurück nach oben
Codeaufteilung
Die Assemblys in .NET Framework wurden einer Leistungsoptimierung unterzogen. Vorkompilierter systemeigener Code wurde pro Funktion in mehrere Bereiche aufgeteilt. Daher kann die vorhandene ICorProfilerInfo::GetCodeInfo-Methode den Umfang des systemeigenen Codes einer Funktion nicht mehr richtig beschreiben. Profiler sollten stattdessen die allgemeinere ICorProfilerInfo2::GetCodeInfo2-Methode verwenden.
Zurück nach oben
Aufhebung des prozessinternen Debuggens
In .NET Framework 2.0 wurde das prozessinterne Debuggen durch eine Gruppe von Funktionen ersetzt, die gegenüber der Profilerstellungs-API konsistent sind. Daraus sind die Funktionen für Stapelmomentaufnahme (siehe Übersicht über die Profilerstellung) und Objektüberprüfung hervorgegangen.
Zurück nach oben
Rückrufe mit dem Native Image Generator
Deutliche Optimierungen im Native Image Generator (NGen.exe) haben dazu geführt, dass noch mehr Arbeit von der Laufzeit auf die Generierung von systemeigenen Abbildern verlagert wurde. Dies hat zu folgenden Änderungen im Verhalten der Profilerstellungs-API geführt:
Für die meisten Funktionen werden JITCachedFunctionSearch-Rückrufe nicht mehr in systemeigenen Abbildern empfangen. Ein Profiler hat je nach Verwendung von Rückrufen zwei Möglichkeiten:
Wenn der Profiler Rückrufe verwendet, um Informationen über eine Funktion zu sammeln, kann er zu einem Schema wechseln, bei dem Informationen über eine bestimmte Funktion nur gesammelt werden, wenn diese Funktion zuerst während der Programmausführung gefunden wird.
Wenn der Profiler Rückrufe verwendet, um zu erzwingen, dass eine Funktion zu Instrumentationszwecken Just-In-Time (JIT)-kompiliert wird, kann er stattdessen durch den Profiler verbesserte systemeigene Abbilder verwenden. Weitere Informationen finden Sie unter Codegenerierung in der Profilerstellungs-API.
Für die meisten Typen werden ClassLoad-Rückrufe nicht mehr in systemeigenen Abbildern empfangen. Profiler sollten für solche Klassen Laufzeitauswertungsverfahren (auch verzögerte Auswertung genannt) verwenden. Profiler, die bereits durch den Profiler verbesserte systemeigene Abbilder verwenden, müssen ihr Verhalten nicht ändern. Da sich durch den Profiler verbesserte systemeigene Abbilder von regulären Abbildern stark unterscheiden, sollte ein Profiler diese Abbilder nur dann verwenden, wenn er sie unbedingt benötigt.
Zurück nach oben
Verbesserte Garbage Collection-Rückrufe
Die Garbage Collection-Rückrufe wurden in mehrerer Hinsicht verbessert. Rückrufe benachrichtigen den Profiler jetzt, wenn Garbage Collection-Handles erstellt oder zerstört wurden, stellen Informationen über das Einreihen von zu finalisierenden Objekten in Warteschlangen bereit und verwenden die Collect-Methode, um eine Garbage Collection zu erzwingen. Die ICorProfilerCallback2::RootReferences2-Methode, die eine Erweiterung von ICorProfilerCallback::RootReferences ist, stellt Informationen über den Typ jedes Stamms bereit. Schließlich meldet die ICorProfilerCallback2::SurvivingReferences-Methode das Layout von Objekten im Heap, das durch eine nicht komprimierende Garbage Collection verursacht wird.
Zurück nach oben
Fixierte Objekte
Fixierte Objekte, eine Neuheit in .NET Framework 2.0, sind konstante Objekte, die zum Zeitpunkt der Generierung von systemeigenen Abbildern initialisiert und in das systemeigene Abbild geschrieben werden. Fixierte Objekte werden durch die Garbage Collection nicht verschoben, können aber von Garbage Collection-Objekten referenziert werden. Die neue ICorProfilerInfo2::EnumModuleFrozenObjects-Methode ermöglicht Profilern, fixierte Objekte aufzulisten.
Zurück nach oben
Verschiedene API-Änderungen
In .NET Framework 2.0 wurden außerdem die folgenden API-Änderungen eingeführt:
Die ICorProfilerInfo::SetFunctionReJIT-Methode gibt jetzt E_NOIMPL zurück. In früheren Versionen führte ein Aufruf dieser Methode zu einem Deadlock.
Die neue ICorProfilerCallback2::ThreadNameChanged-Methode stellt Benachrichtigungen zu geänderten Threadnamen bereit.
Die neue ICorProfilerInfo2::GetThreadAppDomain-Methode akzeptiert eine Thread-ID und gibt die Anwendungsdomäne zurück, in der dieser Thread ausgeführt wird.
Zurück nach oben