Thursday Oct 27, 2016

G1 and Flight Recorder's -XX:FlightRecorderOptions=stackdepth option

Recently there was a report from a customer that they observed performance degradation while using JFR with G1 when they used it along with -XX:FlightRecorderOptions=stackdepth=512, but didn't see any performance impact when using the same setting for the stackdepth with the Parallel Collector. The flight recordings revealed that the poor performance was due to the long pauses introduced by the JFRCheckpoint operations. The long JFRCheckpoints occurred only for the recordings started with -XX:FlightRecorderOptions=stackdepth=512. When tested with -XX:FlightRecorderOptions=stackdepth=3, there were no long pause JFRCheckpoint operations.

Lets look at the possible reasons for that. The time taken by the JFRCheckpoint operations is directly proportional to the amount of data that needs to be written to the disk. In G1, TLAB size is smaller, so in effect it generates more number of 'Allocation in TLAB' and 'Allocation outside TLAB' events. And if we increase the stack depth using 'stackdepth' option, in G1 we'd have much more stack traces data to be written to the disk as compared to the other collectors.

I ran a simple test where I started a GC intensive application first with the Parallel collector, and then with the G1 collector. For both of these tests, I started HotSpot Default recording, and then started a manual time-fixed recording with the profile settings. Observations:

1. The number of GC events created in case of G1 are much more than the parallel collector.
2. The TLABs are smaller in G1 and that leads to the generation of more allocation events in comparison to the parallel collector.
3. If we compare the size of the file written for a 2 minute profile recording with both the collectors, for G1 the size was 3M and for parallel collector it was 600K. This shows that the amount of data that gets written to the disk with G1 collector is more as compared to the ParallelGC, and that contributes towards longer JFRCheckpoint pauses.

To summarize, if you are using JFR with the G1 collector, my suggestion would be to either use the default value for the 'stackdepth' which is 64, or use an even lower value if you observe long JFRCheckpoint operations.

Thursday Apr 02, 2015

Updates to the Java Troubleshooting Guide

Mattis Castegren who is my manager at Oracle, and is the guest writer for this blog post would like to share some details on the Java Troubleshooting Guide. Here's what he has to say:--

With the release of JDK 8, the official Java Troubleshooting Guide got a big overhaul. All pages were looked over and updated for JDK 8, and the two previous guides for the JVM and for Desktop Technologies were merged into one.

In the last month, with the release of 8u40, we have launched the next phase in this project. In this phase, we have added a lot of chapters about the new supportability tools that have been introduced in Java over the last few years.

The biggest new additions are a set of pages on how to use the Java Flight Recorder (JFR). If you haven't used JFR before, you should definitely check out the following chapters:

2.3 What are Java Flight Recordings

2.4 How to Produce a Flight Recording

2.5 Inspect a Flight Recording

These chapters contain step by step instructions on how to record a JFR and also goes through what to look for in a recording to find common issues. The chapters contain lots of screen shots and details on how to interpret the data.

Once you have learned the basics, you can also look at the following two chapters on how to use JFR to debug specific issues:

3.1 Debug a Memory Leak Using Java Flight Recorder

4 Troubleshoot Performance Issues Using JFR

When you have read through these chapters, you will be ready to use this great tool to find bottle necks in your own application.

Other new additions to the troubleshooting guide is a new chapter on how to set up Java for better troubleshooting: Prepare Java for Troubleshooting, as well as a lot of minor updates and clarifications.


I share my work experiences as a JVM Sustaining Engineer through this blog


« February 2017