Lightweight Asynchronous Sampling Profiler with JProfiler (AsyncGetCallTrace)

Question

I recently read a blog entry by Jeremy Manson (Google), about how a more accurate and lightweight asynchronous sampling profiler. It relies on the "AsyncGetCallTrace" undocumented method in hotspot JVMs to gather the stack trace of a thread.

http://jeremymanson.blogspot.fr/2013/07/lightweight-asynchronous-sampling.html

My question to the JProfiler community is: can JProfiler in its current 7.2.3 version use AsyncGetCallTrace? Is this feature in the work for say JProfiler 8.0?

Rhombohedral

Answer 1

The tools interface of the JVM (JVMTI) that is used by profilers has a large test harness that ensures its compatibility and stability for each release. AsyncGetCallTrace is not part of that specification. The overhead of GetStackTrace is so low that it is not advisable for a general purpose profiler to sacrifice the benefits of a supported API for the percieved gains of an unsupported method.

Connivance

Indeed AsyncGetCallTrace is only supported for JVMs derived from the open-jdk project. It would not be an option for a general purpose tool like JProfiler to rely only on it. But I thought JProfiler could support it as an option when the right JVM is detected. That would make it stand out from standard JVMTI based solutions. When profiling our in-memory, multithreaded analytic database, standard stack trace collection is becoming an important bottleneck, and source of profiling inaccuracy. – Rhombohedral

I've added it to our issue tracker, we'll investigate on what platforms this is workable. – Connivance

Thanks for doing it Ingo. I hope you guys will have time to investigate. Reading some comment in a blog entry by Jeremy Manson, it appears AsyncGetCallTrace is available in hotspot JVMs for any platform). – Rhombohedral

A link to that blog entry: jeremymanson.blogspot.fr/2013/07/… – Rhombohedral

The overhead of GetStackTrace may have been able to be considered low a few years ago, but for a very large class (& growing) of applications this really isn't the case any more. Still, good to see that you're considering supporting it, and it will also help the case that JVMTI needs revisiting. – Appendix