Using Java Flight Recorder

JFR Recording with jcmd

On the same host and userid as the java process under analysis, run the following command to start a recording:

 
jcmd JVMID JFR.start filename=rec.jfr

Where JVMID is either the process ID or the classname assigned with the java process as shown when running jcmd without parameters.

To stop a recording, use:

 
jcmd JVMID JFR.stop name=1

To start a recording with more detailed metrics, use the following instead:

 
jcmd JVMID JFR.start filename=rec.jfr settings=profile

Analyzing a JFR Recording

It is recommended to open and read Azul Zulu Prime JVM Java Flight recordings using Azul Mission Control tool available for download from the Azul website.

Alternatively, a Java Flight recording can be viewed using the jfr command-line tool.

Example usage of the jfr command:

 
$JAVA_HOME/bin/jfr print rec.jfr > file.txt

Using the Azul Mission Control Desktop Application

With the Azul Mission Control application, you can also start and stop recording or interactively browse metrics of the java process under analysis.

By default, JFR uses a Unix socket for communication and therefore does not offer remote connections. To allow remote connection, you need to enable the JVM’s JMX connector.

See "Find JVM to connect" to in the Zulu® Mission Control Quick Start Guide for details.

Starting a Recording at JVM Start Time

For detailed performance analysis, you might prefer to start a JFR recording directly when launching a java process.

To enable recording, add either of the following command-line options to the java process under analysis:

More Java Flight Recorder command-line options are listed in Using ZVM Command-Line Options.

Using Zing Live Objects

Zing Live Objects help determine the type of objects that are leaking while troubleshooting memory leaks. To identify and address a memory leak using information gathered in a Zing flight recording, complete the following steps.

To create a Zing flight recording for inspection, use the following arguments:

 
java -XX:StartFlightRecording=disk=false,duration=<recording_time_duration>,settings=profile,filename=<recording_filename>.jfr

The Flight Recorder has two configuration files: default and profile.

To enable the Live Objects feature, you need to enable ZingOldObjectSample in the configuration file. By default, ZingOldObjectSample is enabled only in the profile configuration file in versions of Zing prior to 19.12.0.0. Starting with ZVM 19.12.0.0, ZingOldObjectEvent is disabled by default in all configurations.

By default, the amount of live set events recorded by Java Flight Recorder is set to 99%. To decrease the recording file size, you can set the value of the JFRDescribeLiveSetPercentage command-line option to a number less than 99:

 
java -XX:JFRDescribeLiveSetPercentage=90 -XX:StartFlightRecording=disk=false,duration=<recording_time_duration>,settings=profile,filename=<recording_filename>.jfr

When a recording is started, the output should look similar to the snippet below:

 
$ /home/username/<JDK_installation_path>/bin/java ‑XX:StartFlightRecording=disk=false,settings=profile,filename=myrecording.jfr
Started recording 1.
Use jcmd 32747 JFR.dump name=1 to copy recording data to file.

If just a filename without a path is specified (i.e., filename=<recording_filename>.jfr), the flight recording is saved to the directory from which you ran the command.

To specify the path of your choice, use:

 
filename=<path>/<recording_filename>.jfr

Once you create a Zing Flight recording, start the Azul Mission Control tool and open your Azul Zulu Prime JVM Flight recording from the File menu.

If you do not have Azul Mission Control on your machine, download the installer file from Download Azul Mission Control and see Downloading and Starting Azul Mission Control for installation instructions if needed.

In the Outline navigation tree, select Memory > Zing Live Objects to display the set of live objects captured in the recording.

Study and compare GC cycles in the table with garbage collection identifiers (GC ID) for a live set suddenly increasing in size which indicates a memory leak.

Live objects types marked during each selected GC cycle display in the table to the right when a specific GC cycle is chosen.

Sort out live objects in a GC cycle by the total size to track the live object type with the biggest size and select a potentially leaking object type in the Referent column.

All items that refer to a potentially leaking object type display in the Referrer column in the bottom table. The latter helps identify the source of the leaking object by reference count.

(Optional) To retrieve more information, repeat step 5 if needed.

When a potentially leaking class is identified on the Zing Live Objects sub-tab, use the Memory tab to get information about the allocation site. The Memory tab contains allocation sites, which lead to allocation in a new thread local allocation buffer (TLAB) or allocation outside a TLAB, sorted by type. Checking stack traces for a potentially leaking class can help to stop the real place in code where the leak occurs.

In case the Memory tab does not help to find the leak, but the leak is still suspected, the Method Profiling tab might be used for this purpose. It is less convenient compared to the Memory tab, as it shows method calls of concrete types, not allocation sites.

Usually, the Zing Live Objects sub-tab and the Memory tab are all you need to find a leak.

Inspect the Stack Trace of your candidates to track where most memory allocation pressure comes from.

Using TTSP JFR Events

Azul Platform Prime 20.07.0.0 introduces support for profiling Time To Safepoint (TTSP) issues based on data about the Azul Zulu Prime JVM events collected in a Java Flight Recording (JFR).

To profile an existing TTSP issue using information gathered in a flight recording, complete the following steps: