BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JAX London: Production Time Profiling Using Java Flight Recorder

JAX London: Production Time Profiling Using Java Flight Recorder

This item in japanese

This year at JAX London, Ola Westin of the Java platform group at Oracle presented on Java Mission Control (JMC) and Java Flight Recorder (JFR).

After starting with the overview of both JMC and JFR, Westin showed the audience how a recording can be created and analyzed, and then provided the audience with a demo. In this article, InfoQ will walk its readers through Westin’s presentation.

/Users/monicabeckwith/Desktop/JFRJMC.jpg

Overview of Java Mission Control

Java Mission Control is the graphical interface which helps visualize Java Virtual Machine (the Java VM) behavior with the help of a JMX console (that provides a raw view of the server) and a Java Flight Recorder (that collects, profiles and helps diagnose the application data).

The JMC (command jmc) is bundled with the Java Development Kit (JDK) and is available in the bin directory. Additional logging can be enabled using the –consoleLog –debug options. Various experimental plugins (such as for DTrace, JMX Console, etc) are available for download from within the JMC.

Overview of Java Flight Recorder

Java Flight Recorder collects information on the Java application behavior as well as the Java VM behavior. The JFR is built into the Java VM and provides users with runtime information. The usage of JFR doesn’t interfere with any Java VM optimizations and has a minimal overhead of <2%.

JFR has different events such as instant events, duration events and request-able events. The instant events happen at a single point in time (such as thread start) hence will have the lowest overhead, but the duration events (such as garbage collection, etc) are based on thresholds and similarly the request-able events (such as method profiling samples) are based on a configurable period and hence the overhead will vary for those events.

The sampling profiler for JFR doesn’t require the threads to be at a safepoint and doesn’t log every single method call (only detects hot methods). As of this presentation, there is no sampling for threads invoking native code.

There are two different kinds of recording: time-fixed (profiling) recordings and continuous recordings. Both are dumped to a file.

Creating Recordings

In order to start recording using JFR, you will have to start the JVM with the following commandline options: -XX:+UnlockCommercialFeatures -XX:+FlightRecorder

Starting with Java 8 update 40, it is also possible to create a JFR recording at runtime using either the JMC or the jcmd option.

The following three figures show how a JFR recording can be created using one of the three options listed above.

strt.jpg

strt2.jpg

strt3.jpg

One could also record on a remote system as shown in the following figure:

remote.jpg

Analyzing Recordings

Westin’s presentation highlighted the importance of asking the right questions before diving into any investigation. He then proceeded to provide a demo which highlighted a “hot method” issue as shown below:

hotmethods.jpg

Here, when the “Hot Methods” tab is selected, we can see that LinkedList.indexOf(Object) takes 97.35% of the total samples collected. As we drill down the stack, we find that we have a contains(Object) method in a linked list which requires O(n) iterations. In order to fix this, Westin ran another JFR recording which replaced LinkedList with HashSet. The results are shown below.

hotmethod_fixed.jpg

Westin then provided two additional demos: one on thread contention and another one on allocations due to autoboxing. He then summarized with the future slide shown here:

You could work with Westin's demos and more from Marcus Hirt of Oracle's weblog available as a zip package here.

Rate this Article

Adoption
Style

BT