Share via


Profiling Changes in the .NET Framework 2.0

The profiling API was enhanced in the .NET Framework version 2.0 to provide additional capabilities. The new functionality is exposed through two new interfaces: ICorProfilerCallback2 and ICorProfilerInfo2.

A profiler DLL that was written for the .NET Framework version 1.0 or 1.1 will not work correctly in the .NET Framework 2.0 common language runtime (CLR) environment. To update your profiler DLL to work with version 2.0, you must implement the ICorProfilerCallback2 interface. The ICorProfilerInfo2 interface inherits from the ICorProfilerInfo interface and introduces new methods that support enhanced interaction with the CLR.

Generics

The introduction of generics into the runtime has caused three changes in the profiling API:

Code Splitting

The assemblies in the .NET Framework have undergone a performance optimization. Precompiled native code has been split into multiple regions per function. Therefore, the existing ICorProfilerInfo::GetCodeInfo method can no longer correctly describe the extent of a function's native code. Profilers should switch to using the more general ICorProfilerInfo2::GetCodeInfo2 method instead.

Removal of In-Process Debugging

In the .NET Framework 2.0, in-process debugging was replaced with a set of functionality that is consistent with the profiling API. The stack snapshot and object inspection features are the result.

Callbacks with the Native Image Generator

Significant optimizations in the Native Image Generator (NGen.exe) have moved even more work from run time to native image generation time. This has led to the following changes in the behavior of the profiling API:

  • For most functions, JITCachedFunctionSearch callbacks are no longer received in native images. A profiler has two options depending on how it uses callbacks:

    • If the profiler uses callbacks to gather information about a function, it can switch to a scheme where information is gathered about a given function only when that function is first encountered during program execution.

    • If the profiler uses callbacks to force a function to be just-in-time (JIT) compiled for the purposes of instrumentation, it can use profiler-enhanced native images instead. For more information, see Code Generation in the Profiling API.

  • For most types, ClassLoad callbacks are no longer received in native images. Profilers should use run-time evaluation techniques (also called lazy evaluation) for such classes. Profilers that are already using profiler-enhanced native images do not have to change their behavior. However, a profiler should not switch to profiler-enhanced native images unless it needs these images for other reasons, because profiler-enhanced native images are significantly different from regular images.

Enhanced Garbage Collection Callbacks

The garbage collection callbacks have been enhanced in several ways. Callbacks now notify the profiler that garbage collection handles have been created or destroyed, provide information about the queuing of objects to be finalized, and use the Collect method to force a garbage collection. The ICorProfilerCallback2::RootReferences2 method, which is an extension of ICorProfilerCallback::RootReferences, provides information about the type of each root. Finally, the ICorProfilerCallback2::SurvivingReferences method reports the layout of objects in the heap that is caused by a non-compacting garbage collection.

Frozen Objects

Frozen objects, which are new in the .NET Framework 2.0, are constant objects that are initialized at native image generation time and burned into the native image. Frozen objects are not relocated by garbage collection, but they may be referenced by garbage collection objects. The new ICorProfilerInfo2::EnumModuleFrozenObjects method enables profilers to enumerate frozen objects.

Miscellaneous API Changes

The .NET Framework 2.0 also introduces the following miscellaneous API changes:

See Also

Concepts

Profiling in the .NET Framework

Key Concepts in the Profiling API

Profiling Overview