Add assembly name to SuperPMI collection #48534
Conversation
For each class, add JIT/EE calls to getAssemblyName so the SuperPMI collections contain this information. This can be useful to try and track down where a particular function in a large method context hive came from. Only do this when `COMPlus_EnableExtraSuperPmiQueries=1` is set.
|
@sandreenko PTAL |
sandreenko
left a comment
There was a problem hiding this comment.
Does it affect the merge duplicate phase? Would two methods compiled under different modules be different now?
what is the easiest way to dump it during replay for a given mc file?
| Packet_SigInstHandleMap = 184, | ||
| Packet_AllocPgoInstrumentationBySchema = 186, // Added 1/4/2021 | ||
| Packet_GetPgoInstrumentationResults = 187, // Added 1/4/2021 | ||
| Packet_GetClassModule = 189, // Added 2/19/2021 |
There was a problem hiding this comment.
why not use some of the retired numbers or do you want them to be together?
There was a problem hiding this comment.
I've never reused retired numbers.
Originally, there was some idea that collections wouldn't be so tightly tied to the particular build of spmi, thus not reusing was a good thing. At this point, we don't try to support that, so we could renumber everything, sort the list, and squash out all the unused numbers, if we wanted.
| (void)info.compCompHnd->getAssemblyName(info.compCompHnd->getModuleAssembly(info.compCompHnd->getClassModule(info.compClassHnd))); | ||
| } | ||
| #endif // DEBUG | ||
|
|
There was a problem hiding this comment.
Does this work out ok for the unusual cases like stubs, LGC, etc...?
|
Just that I know how to use this, can you give an example use-case? Can we use this with |
I was worried about that, but this won't contribute to determining if a function is "unique". The only thing used is the "method identity", which is (1) the IL code, (2) the method signature + calling convention + CorInfoOptions + hot/cold region + jit flags + ISA flags. SPMI basically assumes that if the (salient) "input" to the JIT is the same, it will produce the same output. It's possible there are other inputs that could affect the output, like the assembly, but it's possibly a trade-off between precision and SPMI MCH file size and useful difference of MCs.
(this example was from
I thought about adding it to (for So we'd need a way to figure out which is the "root" assembly name to make outputting a single "-dumpMap" entry valuable.
Are you worried that one of getAssemblyName / getModuleAssembly / getClassModule will fail in these cases (and spmi will crash)? I tried to make repGetAssemblyName() resilient to missing info. The others should also be resilient to garbage, but I could be wrong. I can certainly trigger a collection on this PR and see what we get (beyond what I tested locally). Would we see these things in crossgen? crossgen2? PMI? benchmark run? all of the above? |
Dynamic methods get an artificial "Anonymously Hosted DynamicMethods Assembly" name: The common I see a few names that are GUIDs, e.g., I see a benchmarks function Across all the SPMI collections (including tests), I see 7598 unique assembly names. |
For each class, add JIT/EE calls to getAssemblyName so the SuperPMI
collections contain this information. This can be useful to try and track
down where a particular function in a large method context hive came
from.
Only do this when
COMPlus_EnableExtraSuperPmiQueries=1is set.