Профилирование в .NET Framework 2.0
В платформе .NET Framework версии 2.0 интерфейс API для профилирования был расширен с целью предоставления дополнительных возможностей. Новые функциональные возможности предоставляются посредством двух новых интерфейсов: ICorProfilerCallback2 и ICorProfilerInfo2.
Библиотека DLL профилировщика, написанная для платформы .NET Framework версии 1.0 или 1.1, в среде CLR платформы .NET Framework 2.0 будет работать неправильно. Для обновления библиотеки DLL профилировщика с целью обеспечения поддержки версии 2.0 или более поздней необходимо реализовать интерфейс ICorProfilerCallback2. Интерфейс ICorProfilerInfo2 наследуется от интерфейса ICorProfilerInfo и вводит новые методы, обеспечивающие поддержку расширенного взаимодействия со средой CLR.
Эти изменения рассматриваются в следующих подразделах:
Универсальные шаблоны
Разбиение кода
Удаление внутрипроцессной отладки
Обратные вызовы с помощью генератора машинного кода
Расширенные обратные вызовы сборки мусора
Замороженные объекты
Прочие изменения в интерфейсах API
Помимо изменений в API-интерфейсах был добавлен новый результат HRESULT — CORPROF_E_UNSUPPORTED_CALL_SEQUENCE. Сведения о сценариях, в которых может возвращаться этот результат HRESULT, см. в разделе CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.
Универсальные шаблоны
Внедрение универсальных шаблонов в среду выполнения потребовало внесения трех изменений в интерфейс API для профилирования.
Между маркерами typedef и значениями ClassID, а также между маркерами MethodDef и значениями FunctionID больше не существует взаимно однозначного соответствия. Это является следствием того, что для каждого класса или функции можно создавать экземпляры нескольких типов. Авторам профилировщиков следует ознакомиться с разделом Идентификаторы уведомлений среды выполнения и профилирования, проанализировать использование методов ICorProfilerInfo::GetClassFromToken и ICorProfilerInfo::GetFunctionFromToken в своем коде и переписать код с учетом особенностей универсальных шаблонов. В интерфейсе API для профилирования предоставляется два новых метода, ICorProfilerInfo2::GetClassFromTokenAndTypeArgs и ICorProfilerInfo2::GetFunctionFromTokenAndTypeArgs, обеспечивающие поддержку универсальных шаблонов.
Между идентификатором FunctionID и содержащемся в нем идентификатором ClassID соответствие больше не существует. Процедуры оптимизации совместного использования кода обеспечивают возможность создания других экземпляров для универсального типа совместно используемого кода. Определить ClassID идентификатор FunctionID можно, только проанализировав его в контексте конкретной активации функции.
Существующие информационные методы классов и функций в интерфейсе ICorProfilerInfo не предоставляют сведения об аргументах типа для универсальных типов и функций. Для этой цели предусмотрены методы ICorProfilerInfo2::GetClassIDInfo2 и ICorProfilerInfo2::GetFunctionInfo2. Обратите внимание, что эти методы не всегда могут предоставлять такую информацию; дополнительные сведения см. в разделе Идентификаторы уведомлений среды выполнения и профилирования.
К началу
Разбиение кода
Сборки в платформе .NET Framework подвергались оптимизации с точки зрения производительности. Предварительно скомпилированный машинный код делился на несколько областей для каждой функции. Поэтому существующий метод ICorProfilerInfo::GetCodeInfo больше не может корректно описывать масштаб машинного кода функции. Взамен, профилировщик должен перейти к использованию более универсального метода ICorProfilerInfo2::GetCodeInfo2.
К началу
Удаление внутрипроцессной отладки
В платформе .NET Framework 2.0 внутрипроцессная отладка была заменена набором функциональных возможностей, совместимых с интерфейсом API для профилирования. Результатом этого стали функции создания снимков стека (см. раздел Общие сведения о профилировании) и проверки объекта.
К началу
Обратные вызовы с помощью генератора машинного кода
Благодаря существенной оптимизации генератора образов в машинном коде (NGen.exe) значительная часть работы была перенесена со времени выполнения во время генерирования образов в машинном коде. Это привело к следующим изменениям в поведении интерфейса API для профилирования.
Для большинства функций обратные вызовы JITCachedFunctionSearch больше не поступают в образы машинного кода. У профилировщика есть две возможности, зависящие от способа использования им обратных вызовов.
Если профилировщик использует обратные вызовы для сбора сведений о функции, он может переключиться на схему, в которой собирается информация о данной функции, только при первом появлении функции во время выполнения программы.
Если профилировщик использует обратные вызовы для принудительной JIT-компиляции функции с целью инструментирования, он может воспользоваться вместо этого образами в машинном коде, расширенными профилировщиком. Дополнительные сведения см. в разделе Создание кода в интерфейсе API для профилирования.
Для большинства типов обратные вызовы ClassLoad больше не поступают в образы в машинном коде. Для таких классов профилировщик должен использовать оценку во время выполнения (так называемому ленивую оценку). Поведение профилировщиков, которые уже используют расширенные профилировщиком образы в машинном коде, меняться не должно. Однако профилировщик не должен переключаться на расширенные профилировщиком образы в машинном коде, если эти образы не нужны ему для других целей, поскольку такие образы существенно отличаются от обычных.
К началу
Расширенные обратные вызовы сборки мусора
Обратные вызовы сборки мусора были дополнены несколькими возможностями. Теперь обратные вызовы уведомляют профилировщик о создании или удалении дескрипторов сборки мусора, предоставляют сведения о постановке в очередь объектов, которые необходимо завершить, и используют метод Collect для принудительной сборки мусора. Метод ICorProfilerCallback2::RootReferences2, являющийся расширением метода ICorProfilerCallback::RootReferences, предоставляет сведения о типе каждого корня. Наконец, метод ICorProfilerCallback2::SurvivingReferences сообщает о структуре объектов в куче, которая является следствием сборки мусора без сжатия.
К началу
Замороженные объекты
Замороженные объекты, являющиеся нововведением платформы .NET Framework 2.0, представляют собой постоянные объекты, которые инициализируются во время генерирования образа в машинном коде и записываются в этот образ. Замороженные объекты не перемещаются при сборке мусора, однако объекты сборки мусора могут на них ссылаться. Новый метод ICorProfilerInfo2::EnumModuleFrozenObjects позволяет профилировщикам выполнять перечисление замороженных объектов.
К началу
Прочие изменения в интерфейсах API
В платформе .NET Framework 2.0 были внесены следующие изменения в API-интерфейсы.
Теперь метод ICorProfilerInfo::SetFunctionReJIT возвращает значение E_NOIMPL. В предыдущих выпусках вызов этого метода приводил к взаимоблокировке.
Новый метод ICorProfilerCallback2::ThreadNameChanged предоставляет уведомление об изменениях имен потоков.
Новый метод ICorProfilerInfo2::GetThreadAppDomain принимает идентификатор потока и возвращает домен приложения, в котором выполняется этот поток.
К началу