Repository navigation
Investigate including the SPMI collector as part of the core runtime #85537
Description
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.
Activity
AndyAyersMS commentedon Apr 28, 2023
@dotnet/jit-contrib FYI
jakobbotsch commentedon May 1, 2023
There is a lot of redundancy across method contexts. Digging up my results from the experiment (#59000) I see that compressing individual method contexts reduced the MCH size from 3027 MB -> 500 MB. From an internal email that was further reduced to 470 MB by using a pre-trained dictionary. However, it was beat handedly by compressing the contexts in 1 MB chunks (which was ~82 contexts per chunk on average back then), which resulted in 278 MB.
The main problem with a chunked compression scheme is making it work in parallel SPMI replay; the current model with subprocesses and stride/offset does not lend itself well to it.
Of course individual compression might just be "good enough".
AndyAyersMS commentedon May 8, 2023
Was having some trouble replaying some collections I made while running under BDN. Finally realized I was trying to replay a release collection, and this lead to a bunch of problems.
mcs -dumpMapassumes certain info is always present that may be missingThis is a problem we'll also hit if we try and use SPMI as a customer-facing diagnostic tool. Some possible fixes:
#if DEBUG.Along with this we'd need to track down and fix the cases where replay fails on a fresh collection. Currently there are about 1000 of these in the ASP.NET collection (a bit less than 1% of all collected contexts).
BruceForstall commentedon May 8, 2023
We should fix cases where a collection with release fails to
mcsdump or replay with checked (including replay with JitDisasm/JitDump). Current failure in replay can't affect codegen or we'd have a Checked/Release diff. We do this somewhat with thehackishnames currently.AndyAyersMS commentedon May 19, 2023
We also need to consider that the SPMI code and has always been seen as test only and has never undergone any security analysis, So some extra work would be needed here to ensure that the code is robust and safe.
AndyAyersMS commentedon Jul 19, 2024
Still an intriguing idea, but more though and a lot of work needed. Not in 9.0.