Repository navigation
Support profile instrumentation for inlinees #44372
Description
The jit and runtime currently do not support instrumenting (BBINSTR) of inlined code. Enabling this may prove useful for a number of reasons -- for example we are currently not be able to observe the behavior of methods marked with aggressive inline attributes.
(This doesn't impact dynamic PGO as it instruments Tier0 code where inlining is disabled).
Outline of how to fix this:
- update the jit interface so we can pass a method handle to
allocMethodBlockCounts(or introduce a new method) - update jit interface implementation so that if a method already has a count buffer allocated, it is returned. We will need some way to map from method to profile data.
- update the jit to pass the BBINSTR flag to inlinees, if the root method has it set.
- verify the jit does reasonable things in inlinees when the BBINSTR flag is set.
We could consider keeping inlinee counts separate from root method counts to avoid perturbing current IBC computations (collating all counts in one buffer will change which methods are considered hot by IBC). If we do this then count request and retrieval also need to be updated so the jit can indicate if it wants the counts for a root method or the counts for an inlinee. However this may make it hard to persist out the inlinee data as tooling is not expecting two sets of counts for methods.
At the same time we might want to suppress instrumentation for single-block inlinees to reduce the volume and runtime cost of counts.
So initially inlinee counts should be optional behavior until we can assess impact on IBC.
category:cq
theme:inlining
Activity
Dotnet-GitSync-Bot commentedon Nov 6, 2020
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
AndyAyersMS commentedon Mar 30, 2021
Not clear we'll need this anytime soon, so will move to future.
AndyAyersMS commentedon Sep 12, 2025
Seems like this may be fairly simple; when we added support for instrumenting OSR methods in #61543 we added logic for seeing if a current schema and new schema match; that is is exactly what we need here.
One case that might need more thought is when we have a stale R2R profile with a different schema. In such cases the stale profile will "win" and the schema mismatch will prevent the runtime from installing a new profile and so we won't instrument (seemingly this can already happen for root methods; would be good to verify or refute this). We might want to allow the runtime to overwrite a static profile instead, since the stale profile is basically useless.
JIT: enable instrumentation for inlinees
JIT: enable instrumentation for inlinees (dotnet#119658)