Shark provides no infrastructure for this. JIT code isn't listed as
a header by the dynamic linker so Shark doesn't even know where to
look for symbol information. The profile will show the addresses of
the executed JIT code, but there are a few potential problems. If
the JIT doesn't preserve the frame pointer, the backtrace will be
useless after the top frame. Even with that in place, Shark
collects symbol information at the end of the sampling. This is to
avoid the performance impact of doing symbol lookups during the
sampling. If the JIT reuses the same block of memory for multiple
JIT fragments, then Shark has no idea which code fragment was JIT'd
to a given address when the sample was recorded. The JIT would need
to keep track of every JIT code fragment generated, the original
source it came from, and when the code fragment was generated.
Perhaps this would be interesting to Apple now that OpenGL uses LLVM
to JIT code for software fallback. I've done a bit of profiling of a
GL app that is falling back to software, and Shark currently doesn't
provide much useful information.
