|
Methods that contain no metadata (e.g. of sources are IL Stubs,
DynamicMethod, Expression Trees, etc.) also known as LCG methods are not
reported to profilers via the Profiling API. LCG, introduced in .NET 2.0
timeframe is unique in that it doesn't require the method to be hosted
in an assembly > module > type heirarchy and is GCable in of itself.
This change adds new APIs that notify the profiler of such methods but
since there is no metadata to go lookup, it provides some useful pieces
of information that the profiler author may want to expose to the
profiler user.
In the compilation start method we provide a className (always
dynamicClass), a methodName that can be a set of few predetermined names
like (ILStub_COMToCLR, etc.) or if the user has set the name for the LCG
method that can show up here. For example, when using the Expression
Trees API, the user can specify a friendly name which would be returned
here.
In the jit completed callback we provide information for the native code
start address and size. This is particularly useful to get more accurate
accounting of what the (previously unidentified) code is. At least the
user would know it is JITTed if nothing more (but most likely more
information like what kind of stub).
Furthermore, since this is going to be a profiler callback, the profiler
can initiate a stackwalk and give more contextual information to its
users beyond the pieces of information we can provide here that could
identify what they're encountering.
Finally, there is also the case that today the profiling APIs
underreport JITTed code in the process. Considerable amount of LCG code
can now be present in the program and in security-sensitive environments
where tracking JITTed code for security reasons is important the
profiling apis fall short. In such environments there is also often
restrictions on running with elevated privileges, so procuring this data
through other means (like ETW) may pose a challenge.
|
