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:
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!
That explains a few things!
Marcus, any chance of incorporating this into the official documentation, with a wider discussion of the sampling technology?
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.
I look forward to it. Thanks!
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?