-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for dumping and using precise debug info #61735
Conversation
* In the JIT, add support for dumping the precise debug info out through an environment variable `DOTNET_JitDumpPreciseDebugInfoFile` in a simple JSON format. This is a stopgap until we expose the extra information through ETW events. * In dotnet-pgo, add an argument --precise-debug-info-file which can point to the file produced by the JIT. When used, dotnet-pgo will get native<->IL mappings from this file instead of through ETW events. * In dotnet-pgo, add support for attributing samples to inlinees when that information is present. This changes the attribution process a bit: previously, we would group all LBR data/samples and then construct the profile from all the data. We now do it in a more streaming way where there is a SampleCorrelator that can handle individual LBR records and individual samples. * In dotnet-pgo, add an argument --dump-worst-overlap-graphs-to which can be used in the compare-mibc command to dump out a .dot file containing the flow graph of the methods with the worst overlap measures, and showing the relative weight count on each basic block and edge for the two profiles being compared. This is particular useful to find out where we are producing incorrect debug mappings, by comparing spgo.mibc and instrumented.mibc files.
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
@AndyAyersMS @davidwrighton Can you please take a look? No need to review the SPGO parts in detail yet since it's more or less at a prototype stage. |
src/coreclr/jit/codegencommon.cpp
Outdated
while (InterlockedCompareExchange(&s_flag, 1, 0) != 0) | ||
System_YieldProcessor(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a better lock primitive in the JIT I can use here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is CritSecHolder
, if that would be suitable here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks better, thanks.
Tagging subscribers to this area: @JulieLeeMSFT Issue Details
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Glad to see this moving along.
public long TotalEdgeCount1 => BasicBlocks.Sum(bb => bb.Edges.Sum(e => e.Value.Count1)); | ||
public long TotalEdgeCount2 => BasicBlocks.Sum(bb => bb.Edges.Sum(e => e.Value.Count2)); | ||
|
||
public double ComputeBlockOverlap() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might also look into the Spearman rank correlation as a measure of similarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll look into it.
if (JitConfig.JitDumpPreciseDebugInfoFile() == nullptr) | ||
return; | ||
|
||
static CritSecObject s_critSect; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally we don't want the jit to take locks but using one during bring-up like this is ok.
/// Given some IL offset samples into a method, construct a profile. | ||
/// </summary> | ||
public static SampleProfile Create(MethodIL il, FlowGraph fg, IEnumerable<int> ilOffsetSamples) | ||
public void SmootheFlow() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit ..?
public void SmootheFlow() | |
public void SmoothFlow() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Today I learned that 'smooth' can also be used as a verb. :-)
Gonna merge this as I have some follow-up work that builds on it. @davidwrighton let me know if you have any feedback and I'll address it separately. |
In the JIT, add support for dumping the precise debug info out through
an environment variable
DOTNET_JitDumpPreciseDebugInfoFile
in asimple JSON format. This is a stopgap until we expose the extra
information through ETW events.
In dotnet-pgo, add an argument --precise-debug-info-file which can
point to the file produced by the JIT. When used, dotnet-pgo will get
native<->IL mappings from this file instead of through ETW events.
In dotnet-pgo, add support for attributing samples to inlinees when
that information is present. This changes the attribution process a
bit: previously, we would group all LBR data/samples and then
construct the profile from all the data. We now do it in a more
streaming way where there is a SampleCorrelator that can handle
individual LBR records and individual samples.
In dotnet-pgo, add an argument --dump-worst-overlap-graphs-to which
can be used in the compare-mibc command to dump out a .dot file
containing the flow graph of the methods with the worst overlap
measures, and showing the relative weight count on each basic block
and edge for the two profiles being compared. This is particular
useful to find out where we are producing incorrect debug mappings, by
comparing spgo.mibc and instrumented.mibc files.