It seems Profile Explorer in some scenarios will be missing a lot of work. I have examples where say 20s of CPU work for a process is missing in Profile Explorer but shows up in WPA. This is a bad analysis experience because it misleads the user / analyst causing them to not see this work.
The issue is that Profile Explorer seems to throw away samples from certain JIT code. It seems .NET CLR JIT is supported, as well as ARM Prism emulation. But other JITs like LUA or Java work would hit this issue.
In my trace taken on ARM64, I see work generated from an x64 JIT binary LUA interpreted Scripting language. Additional links:
This issue could happen with other JITed languages like Java as well.
Repro - Load trace with JITed code from LUA - There will be no indication of any samples. Given these by nature the IP will not resolve back to a known module or function, these will be Unknown. I recommend we mark them with Thread name and start module. Something like "JIT_ThreadName_StartModule" or similar so where the work is originating from is more clear.
2nd issue - Prism Emulation Modules / Functions DO show in the samples. However, I am pretty sure there is work to be done so that the Functions are grouped properly and show in the module list.
It seems Profile Explorer in some scenarios will be missing a lot of work. I have examples where say 20s of CPU work for a process is missing in Profile Explorer but shows up in WPA. This is a bad analysis experience because it misleads the user / analyst causing them to not see this work.
The issue is that Profile Explorer seems to throw away samples from certain JIT code. It seems .NET CLR JIT is supported, as well as ARM Prism emulation. But other JITs like LUA or Java work would hit this issue.
In my trace taken on ARM64, I see work generated from an x64 JIT binary LUA interpreted Scripting language. Additional links:
This issue could happen with other JITed languages like Java as well.
Repro - Load trace with JITed code from LUA - There will be no indication of any samples. Given these by nature the IP will not resolve back to a known module or function, these will be Unknown. I recommend we mark them with Thread name and start module. Something like "JIT_ThreadName_StartModule" or similar so where the work is originating from is more clear.
2nd issue - Prism Emulation Modules / Functions DO show in the samples. However, I am pretty sure there is work to be done so that the Functions are grouped properly and show in the module list.