Search code examples
profilingthread-dumpjfr

JFR ExecutionSample vs ThreadDump

  1. What is preferable to use if I need to perform Java profiling with JFR: ExecutionSample event every X millis or ThreadDump event every X millis?
  2. Is there any way to have ExecutionSample event and/or ThreadDump event just for specific thread and not for all threads?
Solution

    1. If you want to sample Java threads, you should use jdk.ExecutionSample as the overhead will be much lower.

    2. There is no way to configure jdk.ThreadDump to only record a single thread, or have jdk.ExecutionSample sample all threads simultaneously.

    Explanation

    The sampler responsible for emitting the jdk.ExecutionSample suspends a Java thread periodically and walks its stack, but all other threads can keep running. The stack trace is stored as an ID, so if it is repeated, only a couple of bytes need to be rewritten.

    The implementation of the jdk.ThreadDump event brings all Java threads to a safepoint, which means the application will stop completely. Running Java threads will only stop at places in the generated machine code where a safepoint poll is located. This means sampling will not be as accurate. When all threads are stopped, all the stacks are walked by a single thread, which means other cores will be waiting. The result is written as text, so if the same stack trace occurs multiple times, all the frames will need to be rewritten.