Why have I more than one JFR recording?

Question

Getting to grips with Java Flight recorder (JFR) configuration, I have a mostly sensible configuration in place:

-XX:+UnlockCommercialFeatures -XX:+DebugNonSafepoints -XX:+FlightRecorder 
-XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,dumponexitpath=../logs 
-XX:StartFlightRecording=compress=true,maxsize=1g

Using JFR.check however shows that I have not one, but two recordings ongoing.

Recording: recording=0 name="HotSpot default" (running)

Recording: recording=1 name="Recording 1" maxsize=1.0GB (running)

How did recording 0 happen?

Answer 1

There has been an effort to simplify the command line. For JDK 11 and later, this is what I would recommend.

$ java -XX:StartFlightRecording:maxsize=1g,filename=../logs

I mention this to reduce the confusion if somebody who reads this is using a more recent JDK.

The reason you get two recordings is that

-XX:FlightRecorderOption=defaultrecording=true 

starts a recording.

To complicate things further, if you want to create a recording where you specify a directory, ie ../logs, to generate a unique filename per JVM process, you need to use

-XX:FlightRecordingOption=dumponexitpath=<directory> 

which on JDK 7/8 only works with the recording started with defaultrecording=true . I think -XX:StartFlightRecording could be removed if you change to this:

-XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,
    disk=true,maxsize=1g,dumponexitpath=../logs

The recording will however not be compressed.

That said, the above will not work on JDK 11 or later, as the defaultrecording=true option has been removed. Instead the functionality has moved into to -XX:StartFlightRecording:filename= option where compression and disk is enabled by default, and dumponexit=true is superfluous if you set a filename.

Inside the JVM there is only one recording running, so don't worry about overhead of several recordings. The reason multiple recordings can be started is to allow configurations to be stacked. For example, you may want to have a low overhead recording running all the time and then start a more intrusive recording for ten minutes. When the ten minutes ends, the JVM will revert back to the low overhead configuration.

There is more, I could write an essay about this, but let's stop here.