Jitted code in a universal trace shows memfd:doublemapper as the module identity instead of the managed assembly name

[noahfalk]

When the .NET jit runs it creates shared memory mappings and writes jitted code into those mappings. Universal traces faithfully report those mappings for jitted symbols. I'd expect PerfView to understand enough about jitted code to map it back to the managed assembly which has the IL and use that for the stack frame name instead.

Actual behavior:
In the stack trace view you see memfd:doublemapper

Expected behavior:
The symbols in the stacktrace would be named using managed assembly names. For example System.Private.CoreLib!void System.Threading.ThreadPoolWorkQueue::Dispatch()

[brianrob]

There are a few different ways that we can go about this. Let's try one and see if we can make it work:

• If the module starts with memfd:doublemapper (there are some that will start with this, but be marked as "(deleted)"), then it is jitted code.
• For jitted in universal traces, the format of the symbol is returnType [module] Namespace.Class::Method(args...)[OptimizationLevel].
• We should parse and use this information when we handle the Universal.System symbol event so that the resulting symbol that we show is module!Method(args...).
• This may require that we setup a Module or LoadedModule for each module that we see, but I'm not 100% sure if these are required.