JDK Flight Recorder: How to use with Mission Control

JFR can periodically capture stack traces for running threads in JVM. This technique is known as sampling profiling and available in all Java profilers. Statistical analysis of a large corpus of stack traces gives an excellent picture of where the application spends most of the time down to method name or even line number. This report provides useful visualization for this subset of data collected by JFR.

This method is typically used in cases where the application is CPU bound. Sampling helps to identify code that is inefficient or can be optimized for better performance.

This report outlines the memory usage statistics of your Java application. It combines multiple data points, with the most important of them being object allocation samples.

If enabled, JFR records samples of new object allocation events, including allocated classes, size of object, and stack trace to the point of allocation. Statistical analysis of these samples can reveal a lot about your code.

The "Memory" report shows top classes of objects being allocated. Information on actual allocated size, including stack trace to the point of allocation, is also available.

This report is most helpful if you want to reduce garbage collector pressure or optimize memory usage. Memory profiling is extremely valuable when it quickly identifies the "littering" code in your application and provides ideas for optimization.

Contentions and deadlocks is another class of Java problems hard to approach without a good tool. JFR collects events of thread blocking on synchronized sections and other concurrency primitives that can be useful during the investigation of Java concurrency problems.

"Lock Instances" report shows you aggregated statistics for these events. "Threads" is another report helpful in tracking down concurrency issues.

A built-in "Profiling" configuration has a threshold on the duration for such events. Keep in mind that you may need to lower it to get a more detailed picture.

The cost of inter-thread contention becomes a harsh reality for high parallel code running on dozens of cores. Java ships with a few concurrency primitives, including lock-free ones. The contention report helps understand the cost of multithreading in your application and possibly highlights bottlenecks where switching to more elaborate locking is most beneficial.

Blocking file and socket I/O operations are also traced by JFR. These reports show aggregated statistics built from file and socket I/O events, respectively.

You can see which files your application has been reading and for how long or at which remote endpoints it has exchanged data.

There is a caveat, though. When using JFR for the first time, you are likely to find both of these reports to be empty or almost empty. The reason is the 10 ms threshold used by default for these kinds of events. If you want to see a full I/O picture, set this threshold to 0 when starting a flight recording session.

This report is very good at catching "unexpected" I/O events buried deep inside the layers of libraries and frameworks.

In this report, you can see various events (contention related, I/O associated, Java thread state changes) put into a unified timeline. Here, you can see the interaction of threads in an intuitive visual way. The ability to zoom into the millisecond level of precision is helpful, too.

Every Java application produces a handful of exceptions at runtime. Some of them end up in log files, but many are suppressed for one reason or another. Silently swallowed exceptions sometimes lead to many hours wasted during the incident investigation afterward.

JFR sees all exceptions (whether they were suppressed or not). There are two kinds of related events. JFR records the total count of exceptions produced by runtime. This metric helps to identify exception misuse. JFR can also record every single exception created, including the stack trace, although you need to tweak the flight recording session’s configuration to get this level of detail.

GC troubleshooting typically involves digging through GC logs. JFR collects detailed information concerning GC events, and this report visualizes this data. Almost any metric of GC present in JVM is available here.

If you need to tune GC or troubleshoot abnormal GC pauses, this is a report to start with.

HotSpot has a concept of VM operations ranging in types. But the critical point is that all of them require the Stop-the-World pause. With some JVM options, you can enable logging of VM operation or use JFR and this handy report.

VM operations are often mistaken for GC pauses (which is just one type of VM operations). Developers tend to blame Stop-the-World on garbage collectors. This report is your first stop if the application is experiencing Stop-the-World pauses.

You can send JFR files for analysis to an expert in the JVM domain. Files include JVM configuration, hardware configuration, and even a list of other processes running on a server and competing for resources without application.