Improving the Fidelity of the JFR Method Profiler

One nice property of the JFR method profiler is that it does not require for the threads to be at safe points for stacks to be sampled. However, since the common case is that stacks will only be walked at safe points, HotSpot normally does not provide metadata for non-safe point parts of the code, which means that such samples will not be properly resolved to the correct line number and BCI. That is, unless you specify:

-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints

With the DebugNonSafepoints, the compiler will generate the necessary metadata for the parts of the code not at safe points as well.

Big thanks to Doug Simon and Gilles Duboscq for noting this!

4 Responses to "Improving the Fidelity of the JFR Method Profiler"

  1. Phil Aston says:

    That explains a few things!

    Marcus, any chance of incorporating this into the official documentation, with a wider discussion of the sampling technology?

    Thanks,

    – Phil

  2. admin says:

    Yep, documentation will see a major upgrade soon! The DebugNonSafepoints flag will likely be set automatically when specifying the -XX:FlightRecorder flag in the future.

  3. Phil Aston says:

    I look forward to it. Thanks!

  4. Travis Downs says:

    So in the (usual) case that the DebugNonSafepoints options is not specified, what happens to the samples that are not taken at safepoints? Will the profiler still try to resolve the instruction pointer to the right bytecode based on the limited information available, perhaps resulting in some skew, but less so than typical only-samples-at-safepoints compilers? Or something else?

Leave a Reply

Your email address will not be published. Required fields are marked *