With the Hotspot JDK 7u40 there is a nifty new tool called Java Mission Control. Users of the nifty old tool JRockit Mission Control will recognize a lot of the features. This particular blog entry focuses on the Java Flight Recorder and various ways you can go about to create a flight recording.
In the last blog entry about the method profiler I showed that Mission Control can be quite useful for profiling production systems. However, I only showed one way to produce the actual recording.
There are several different ways to produce a recording, all of them useful in a certain context. But before we get into that, we should first discuss the two different kinds of recordings.
Continuous recordings are not only very hard to spell, they are also very common in production systems. Well, if Java Flight Recorder will be used anything like the JRockit equivalent, at least they will be. Continuous recordings have no end time and will keep recording until the JVM shuts down, or someone tells it to end. This kind of recording can be dumped at any point in time when access to the data being recorded is needed.
Time Fixed Recordings
Also known as profiling recordings, these recordings run for a fixed amount of time and then automatically end themselves. These typically use templates that enable costlier events, since the performance penalty will only be suffered for a limited duration of time.
Note that it is perfectly feasible to have several recordings running in parallel. It is even quite common. Which brings me to the first quirkiness of the Java Flight Recorder: Recordings active at the same time share the same buffers!
It may be easier to consider recordings to be named sets of Event Type settings, i.e. settings of what to record, that are being pushed and popped from the recording engine. At any given time, the union of the settings dictates what will be recorded.
Here is an example:
A continuous recording R0 is started at T0 with settings S0. After a while, a time fixed recording R1 is started at T1 with settings S1, where S1 ⊃ S0. The time fixed recording R1 ends at T2. This is what will be recorded:
|T1→T2||S0 ∪ S1|
Note that this means that if you dump the continuous recording R0 for a time range intersecting [T1,T2], you will actually find that you are getting information in your “recording” that you did not ask for in the settings (S0). All this in the name of performance. Once T2 arrives, the settings for R1 will be popped, and we’re back to just recording S0.
Now, one last reminder before getting back to the actual recording:
|The 1st Rule of Flight Recording*|
|Thou Shalt Never Forget to Start Your JVM with
(* Only required in HotSpot. With JRockit, no command line flags are required.)
Creating a Recording from Within Mission Control
This is probably the easiest way to produce a recording, since you get help both with connecting to the JVM from which you want the recording, and a nice wizard that helps you to select what to record. I went through the recording wizard in the blog entry about the method profiler, so I will not repeat that here. I will just note that the template settings that you arrive at can be exported from Mission Control, and then stored server side so that anyone connecting to that JVM though Mission Control will have access to it. Simply create a recording with the settings you would like to store, next go to the Template Manager, select the template marked as “ – last saved” and hit Export. Then put the exported file in the jre/lib/jfr folder of the JVM where you want to make the template available.
Creating a Recording Using Command Line Arguments
This is quite useful when you want to record the start up behaviour of an application, or when you want to make sure that your application always starts with a continuous recording running. Since I am a staunch believer of examples, I’ll simply give three examples.
Here is an example of how to start a one minute time fixed recording, 20 seconds after the JVM has started, using the profile template :
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:StartFlightRecording=delay=20s,duration=60s,name=MyRecording,filename=C:\demo\myrecording.jfr,settings=profile
Note that the settings parameter either takes a path to a template, or the name of a template which must be available in the jre/lib/jfr folder of the JVM.
Here is an example on how to start a continuous recording, using the default template:
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:StartFlightRecording=name=MyRecording,settings=default
Note that in the second example we do not specify any file name. The data will need to be dumped on request, either using Mission Control or jcmd, or possibly by using the dump-on-exit parameters to make the JVM dump the recording when exiting the JVM, like this:
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,dumponexitpath=c:\demo\dumponexit.jfr
For more information on the available parameters, see the Java Command Line Reference.
Creating a Recording Using JCMD
You can also control the Flight Recorder even after you have started the java process (as long as you adhere to the 1st Rule of Flight Recording) using JCMD. The JCMD utility is in the JAVA_HOME/bin folder and allows you to enumerate the locally running Java processes, and send commands to them. Just running jcmd will list the running Java processes and their PIDs:
To query a certain JVM for the available commands, use “help”:
C:\Java\jmc5.2labs>jcmd 7484 help
The following commands are available:
For more information about a specific command use 'help <command>'.
Here is an example which starts a continuous recording from the command line using JCMD (assuming that the PID of the Java process you want to record on is 4711):
C:\Java\jmc5.2labs>jcmd 7484 JFR.start name=MyRecording settings=default
4711: Started recording 1. No limit (duration/maxsize/maxage) in use.
Use JFR.dump name=MyRecording filename=FILEPATH to copy recording data to file.
The JFR.check command can be used to check the status of the recordings:
C:\Java\jmc5.2labs>jcmd 4711 JFR.check
Recording: recording=1 name="MyRecording" (running)
To dump the recording:
C:\Java\jmc5.2labs>jcmd 4711 JFR.dump name=MyRecording filename=C:\demo\jcmddump .jfr
Dumped recording "MyRecording", 180.3 MB written to:
Then you can just drag and drop the resulting file into Mission Control to view the contents:
(No blog post is complete without a Pretty Picture™.)
Further reading and useful links
Java Mission Control Finally Released
My JavaOne 2013 Sessions
Low Overhead Method Profiling with Mission Control
The Mission Control home page:
Mission Control Base update site for Eclipse:
Mission Control Experimental update site (Mission Control plug-ins):
The Mission Control Facebook Community Page (not kidding):
Mission Control on Twitter:
Me on Twitter:
I stumbled across your article (nicely written btw,,,) while searching for ways to quickly ascertain if Commercial Features (CF’s) are enabled and/or in use. The only thing I’ve found of value outside of searching for certain logfiles for each of the CF’s is using the “jcmd help” cmd which will print a list of CF’s that are active in the JVM (I realize this may not be an accurate desc of how the JVM actually works). However, If I issue that cmd and get an error message… this is the only way I’ve figured out there are no CF’s enabled. Is there possibly any other method you know of to determine – maybe in PowerShell – whether CF’s are enabled?
If in continuous recording, is there a way to dump the jfr from an mbean?
Yes. There are several. There is a Flight Recorder MBean you can use to control the flight recorder. You can also use the Diagnostic Command MBean.