|
* change profiler rejit to be enabled by default, and also change the debugger to only give up on setting a breakpoint if a method has been rejitted, rather than just whenever rejit is on
* copy corprof changes to the pal version, and change rejit so it is allowable on attach
* Change GetILFunctionBody/SetILFunctionBody to be allowed after attach
* Also make RequestRevert allowable on attach
* change lock order and switch from GC_NOTRIGGER to GC_TRIGGERS in Rejit codepath through the codeversionmanager
* make GetReJITIDs callable after attach
* change profiler rejit to be enabled by default, and also change the debugger to only give up on setting a breakpoint if a method has been rejitted, rather than just whenever rejit is on
* copy corprof changes to the pal version, and change rejit so it is allowable on attach
* Change GetILFunctionBody/SetILFunctionBody to be allowed after attach
* Also make RequestRevert allowable on attach
* change lock order and switch from GC_NOTRIGGER to GC_TRIGGERS in Rejit codepath through the codeversionmanager
* make GetReJITIDs callable after attach
* rename value to enable/disable rejit on attach, and cache values of profiler rejit and config value
* Change places where the jit checks for rejit being enabled to actually check for what it wants, which is whether jump stamps are enabled
* get rid of old value that was readded by merge somehow
* disallow detach after setting rejit event mask, and prevent it from being set if rejit on attach is turned off
* fix incorrect assert
* Take the codemanager lock in SetIP
|
|
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.
|
