The really annoying thing about the tool is that in order to be able to run JFR against your program, the program had to be started with the system properties:
This is not always convenient or even possible in certain runtime environments or where the process has been running a long time and is in a particular state that you would like to profile rather than restart.
Enter the latest jdk 1.8.0_40. With this build of the jdk you no longer need to have those options enabled when you started the java program. Just launch jmc and select your process as per normal and you will be presented with this dialog box.
You will be able to enable those command line options dynamically. An excellent improvement to this excellent product!
Whilst on the topic of command line options for JFR I've started using this system property when running my programs. -XX:+DebugNonSafepoints
According to the documentation:
One nice property of the JFR method profiler is that it does not require threads to be at safe points in order 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:
DebugNonSafepoints, the compiler will generate the necessary metadata for the parts of the code not at safe points as well.
To my mind the whole point of using JFR as opposed to YourKit etc is that it doesn't have to respect safe points and you can get more accurate stats about where time is actually being spent. I have seen evidence of this even without using this system property. But with this option enabled I expect the debug stats are even more accurate. I had a situation where I was looking for hotspot and JFR pointed me to a high level method which didn't help me at all. I then enabled the DebugNonSafepoints JFR pointed me to the exact point in the code where hotspot actually lay - fantastic!