Include runtime flavor and platform information into .mibc Profile

[mdh1418]

With the work to enable PGO-based Profiled AOT on Mono, mono based .mibc files can now be generated. It would be convenient if there was some way to identify the Runtime flavor, Platform OS + Arch for a corresponding .mibc file.

For instance, I had been testing the full pipeline of Profiled AOT on Mono, but unknowingly had generated a coreclr based .mibc (probably accidentally published a coreclr build and collected a .nettrace from the resulting executable). Only after comparing with another .mibc that is more clearly Mono based could we guess that the previous .mibc was a coreclr based one.

/cc: @lambdageek @davidwrighton @lateralusX @tommcdon

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.

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

With the work to enable PGO-based Profiled AOT on Mono, mono based .mibc files can now be generated. It would be convenient if there was some way to identify the Runtime flavor, Platform OS + Arch for a corresponding .mibc file.

For instance, I had been testing the full pipeline of Profiled AOT on Mono, but unknowingly had generated a coreclr based .mibc (probably accidentally published a coreclr build and collected a .nettrace from the resulting executable). Only after comparing with another .mibc that is more clearly Mono based could we guess that the previous .mibc was a coreclr based one.

/cc: @lambdageek @davidwrighton @lateralusX

Author:	mdh1418
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[lambdageek]

There are a couple of subtasks here:

• Extend the mibc format to include optional runtime information - at the very least profile platform/architecture and runtime flavor (coreclr vs mono vs ...). For example I wonder if collecting a profile on coreclr x64 and deploying to arm64 is worth at least a warning.
• Extend the information in .nettrace files (rundown?) to include platform info and runtime flavor.
• Make changes to the dotnet-pgo tool to shovel the platform info from .nettrace to .mibc

[lambdageek]

I don't think we necessarily want a profile to become unusable if it's from the "wrong" runtime/platform, but it would be easier to diagnose profile issues if there was an option for the runtime to report that profile XYZ doesn't match platform/runtime ABC

[EgorBo]

I planned to try to extend the MIBC format too, was planning to add:

1. versioning
2. "is it app specific or some common profile" flag
3. working set size

[tommcdon]

Adding @davidwrighton @mangod9 who own the mibc format

[davidwrighton]

This seems pretty good. Adding an extra method to the PGO data to encode this data should be straightforward. I'd like to see it structured as a key/value store. Probably with just strings for keys and values.

[lateralusX]

There are a couple of subtasks here:

• Extend the mibc format to include optional runtime information - at the very least profile platform/architecture and runtime flavor (coreclr vs mono vs ...). For example I wonder if collecting a profile on coreclr x64 and deploying to arm64 is worth at least a warning.
• Extend the information in .nettrace files (rundown?) to include platform info and runtime flavor.
• Make changes to the dotnet-pgo tool to shovel the platform info from .nettrace to .mibc

When closing a session there is a process info event emitted, it includes command line, os info as well as CPU architecture, but currently not runtime flavor.

[tommcdon]

I planned to try to extend the MIBC format too, was planning to add:

1. versioning
2. "is it app specific or some common profile" flag
3. working set size

@EgorBo has agreed to take a look at adding the runtime flavor info to the MIBC file format. @EgorBo please let me know if any help/assistance is need with adding the runtime flavor to the process info event.

[EgorBo]

When closing a session there is a process info event emitted, it includes command line, os info as well as CPU architecture, but currently not runtime flavor.

Thanks, I see ProcessInfo event that contains OS and Arch.

Adding an extra method to the PGO data to encode this data should be straightforward. I'd like to see it structured as a key/value store. Probably with just strings for keys and values.

@davidwrighton do you mean like

ldstr "key1"
ldstr "value1"
pop
pop
ldstr "key2"
ldstr "value2"
pop
pop
...

?