As part of the work to enable PGO by default we are considering ways to enhance diagnosability of PGO related issues.

The benefit of including SPMI collection as part of the core runtime is that it would then be easy to have customers enable SPMI collection to report codegen issues, and we could accurately replay jit behavior for diagnostic purposes without needing to run the customer code. SPMI can capture the actual PGO data used by the jit, which can differ substantially from the PGO data present in the process dump taken sometime after a method is jitted.

• Size impact: the winx64 superpmi_shim_collector is a 200KB sideloaded DLL (core runtime is 5.3 MB) so an initial take is that it is a lot of extra size for something that may not be frequently used. But the collector likely has a lot of code in common with the runtime so the merged size may be considerably less. Need to investigate.
• Time overhead: if the collection process has too much overhead it may alter runtime behavior. Also need to investigate.
• Memory/Disk impact: SPMI collections are large and probably can’t be kept in memory. We should look at ways to make them more compact (perhaps on the fly compression) and or ways to have a “rolling buffer” capability where the total memory impact is bounded and older method info is eventually tossed. SPMI more or less captures a “packet” per jitted method so there are natural atomic chunks that can be compressed / kept/ discarded.
• Externalization: the collection data is in process so we need some way to get it out; this can be via SOS command or eventing or explicit file writes. We may need some combination here to handle all the various scenarios. Externalization needs to be robust in the presence of crashes.

Shipping the current sideloaded DLL would also be an option, but it would need to version with the runtime as the collector relies on the exact implementation of the JIT-EE interface.