-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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 a config to MIBC format #71359
Add a config to MIBC format #71359
Conversation
Let me know if I e.g. should serialize it to e.g. JSON or CSV and put into a single |
One could also serialize this info as custom attributes. The ldstr/pop and ldtoken/pop is used for the rest of the MIBC stuff because it's more compact than custom attributes. We don't care about compactness for metadata that much. Custom attributes look nicer when looked at in e.g. ilspy. One could use AssemblyMetadataAttribute from mscorlib so that it even nicely resolves to something. But not sure if it's a scenario we need to optimize for and you already wrote the code to use ldstr/pop... |
config.Arch = processInfo?.PayloadByName("ArchInformation")?.ToString(); | ||
|
||
// Look for Sku, e.g. "CoreClr" | ||
TraceEvent runtimeStart = p.EventsInProcess.Filter(t => t.EventName == "Runtime/Start").FirstOrDefault(); |
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.
How does the Sku work (what does it stand for)? It would be nice to have the mono runtime be emitted, so if we use the Sku for emitting runtime, would it be unproblematic to extend the Sku enum to also contain Mono (not sure if there is a trickle effect)? What is the Runtime/Start
event/where do i look to find it?
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 wasn't sure what to pick for runtime so probably it would be easier if you tell me which event to analyze cc @lateralusX
I just opened a random nettrace via PerfView and searched for CoreCLR - this was the first thing to pop up - I assume mono runtime is expected to send this exact event on start with a different value for Sku
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.
If that eventname is the same as FireEtwRuntimeInformationDCStart
, it seems to be the right event. I think we can try adding mono to the Sku Enum, right now we are emitting CoreCLR as well on Mono
runtime/src/mono/mono/eventpipe/ep-rt-mono.c
Line 2804 in 41d9c1c
RUNTIME_SKU_CORECLR, |
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 don't see FireEtwRuntimeInformationDCStart
in my sample nettrace
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.
Here is the events we collect - Microsoft-Windows-DotNETRuntime:0x1F000080018:5
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.
So I assume the current impl is correct as is, right? it does poll "Runtime/Start" event and extract Sku so once Mono is added we're all set
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.
@lateralusX @EgorBo I'm thinking the value should be 0x4 as 0x3 will show up as DesktopClr, CoreClr since it matches those bits (0x1 || 0x2). I obtained a trace with --providers Microsoft-Windows-DotNETRuntime:0x1F000080018:5
on mono and it indeed shows the sku value within the mibc file. https://gist.github.com/mdh1418/2e9ad2d937dbdd0fb0be063c15eff61a
I also verified that we should be able to obtain the actual Sku value from the Mono AOT Compiler side as well. I'll put up a separate PR to integrate the .mibc file validation.
I think we should extend the relevant Sku structs and Mono additions I mentioned earlier
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.
Is anything treating the sku as a bit set? Seems like it shouldn't be.
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.
@jakobbotsch I'm not sure what the main rationale is between making something a bitmap vs a valuemap, but this might be why its behaving as such
runtime/src/coreclr/vm/ClrEtwAll.man
Line 611 in 4a63cb2
<bitMap name="RuntimeSkuMap"> |
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 see, seems reasonable then.
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, couple of nits you can consider
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 realized I forgot to submit the comments so all of my comments were pending 😅
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IBC/MIbcProfileParser.cs
Outdated
Show resolved
Hide resolved
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IBC/MIbcProfileParser.cs
Outdated
Show resolved
Hide resolved
config.Arch = processInfo?.PayloadByName("ArchInformation")?.ToString(); | ||
|
||
// Look for Sku, e.g. "CoreClr" | ||
TraceEvent runtimeStart = p.EventsInProcess.Filter(t => t.EventName == "Runtime/Start").FirstOrDefault(); |
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 extended the Sku Enum to have Mono 0x4 in both src/coreclr/inc/eventtracebase.h
and src/coreclr/nativeaot/Runtime/eventtracebase.h
typedef enum _Sku
{
DesktopCLR=0x1,
CoreCLR=0x2,
Mono=0x4
}Sku;
and the generated .nettrace is still compatible with perfview and visual studio (as in no throws or crashes from viewing the .nettrace). The only catch is that the value of Sku is literal Sku="4"
compared to Sku="CoreClr"
and Sku="DesktopClr"
. I believe that is because the libraries define the Sku as RuntimeSku
with only enum vars for 0x1 and 0x2. https://github.com/microsoft/perfview/blob/8f5c46ad3980ecbd8845bff274911ecb22f98f3f/src/TraceEvent/Parsers/ClrEtwAll.cs.base#L6902-L6906
I'm not sure if there are other tooling or more advanced usages of .nettrace Rundown Runtime/Start events that leverage the value of Sku, but if this is the only extent, then it looks like we are good to go to with using the event.
@EgorBo can we include extending the Sku in this PR?
typedef enum _Sku
{
DesktopCLR=0x1,
CoreCLR=0x2,
Mono=0x4
}Sku;
in both src/coreclr/inc/eventtracebase.h
and src/coreclr/nativeaot/Runtime/eventtracebase.h
and changing the
#define RUNTIME_SKU_CORECLR 0x2
to #define RUNTIME_SKU_MONO 0x4
runtime/src/mono/mono/eventpipe/ep-rt-mono.c
Line 153 in ade0b21
#define RUNTIME_SKU_CORECLR 0x2 |
as well as the rundown event Sku value
runtime/src/mono/mono/eventpipe/ep-rt-mono.c
Line 2804 in ade0b21
RUNTIME_SKU_CORECLR, |
to be
RUNTIME_SKU_MONO
config.Arch = processInfo?.PayloadByName("ArchInformation")?.ToString(); | ||
|
||
// Look for Sku, e.g. "CoreClr" | ||
TraceEvent runtimeStart = p.EventsInProcess.Filter(t => t.EventName == "Runtime/Start").FirstOrDefault(); |
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.
@lateralusX @EgorBo I'm thinking the value should be 0x4 as 0x3 will show up as DesktopClr, CoreClr since it matches those bits (0x1 || 0x2). I obtained a trace with --providers Microsoft-Windows-DotNETRuntime:0x1F000080018:5
on mono and it indeed shows the sku value within the mibc file. https://gist.github.com/mdh1418/2e9ad2d937dbdd0fb0be063c15eff61a
I also verified that we should be able to obtain the actual Sku value from the Mono AOT Compiler side as well. I'll put up a separate PR to integrate the .mibc file validation.
I think we should extend the relevant Sku structs and Mono additions I mentioned earlier
@mdh1418 We should extend ClrEtwAll.man with the new enum values as well as strings. Since this PR has been merged, we need do it in separate PR. Once we have the ClrEtwAll.man extended, we should also make sure perfview and EventTrace library correctly handles the new enum value. @brianrob can guide you through the steps needed to update these libraries in order to align to extensions to ClrEtwAll.man. |
Closes #71065
This PR adds the following global method to *.mibc -
![image](https://user-images.githubusercontent.com/523221/176061310-22016b7c-fddb-4967-bc60-446a0a1da995.png)
MibcConfig
that stores key-value config like this (similar toAssemblyDictionary
method):When we merge multiple mibc we just take the first valid config for the merged mibc.
When we do "dotnet-pgo dump" it's displayed like this: