This chapter serves as an introduction to the Oracle JRockit Flight Recorder. It contains these sections:
Have you ever wondered what really happens in a running Java program? Have you ever wanted to "go back in time" and analyze what happened right before a problem occurred in your system? Do you want an extremely detailed level of profiling without impacting performance? JRockit Flight Recorder has been engineered to meet all of these goals.
JRockit Flight Recorder does all this by being tightly integrated into the core of the JVM itself and by being very conscious of its performance overhead. JRockit Flight Recorder provides a wealth of information on the inner workings of the JVM as well as on the Java program running in the JVM. You can use this information for profiling and for root cause analysis of problems. Furthermore, JRockit Flight Recorder can be enabled at all times, without causing performance overhead—even in heavily loaded, live production environments.
While capturing details about the JVM, the JRockit Flight Recorder has also been tightly integrated into Oracle's Fusion Middleware family of products and provides a full stack view of the system. Everything from Java servlets and database execution at a high level to fine-grained information on thread synchronization and garbage collections is available at your fingertips.
JRockit Flight Recorder is comprised of a recording engine, which sits inside the JVM, and the JRockit Mission Control client. The engine produces a recording file which can later be analyzed through the client. This document primarily deals with configuration of the first part, the JVM, and only briefly mentions the JRockit Mission Control GUI (see Chapter 2, "Quick Start Procedures").
The JRockit Flight Recorder has three primary uses:
Because JRockit Flight Recorder continuously saves large amounts of data about the running system, it can operate as a profiler. Profiling information includes thread samples, which show where the program spends its time, as well as lock profiles and garbage collection details
Like its aeronautic namesake, JRockit Flight Recorder can also operate as a "black box," continuously saving information to a circular buffer. This information then can be accessed when an anomaly is detected. This information can be essential to quickly finding performance issues in a deployed system.
JRockit Flight Recorder provides information that can provide Oracle support personnel with important clues for diagnosing issues with the software.
The basic principle underlying JRockit Flight Recorder is that every piece of data it captures is an event. An event is something that happens in the running application at a specific point in time. Events have a name, a time stamp, and an optional payload. The payload depends on the type of the event; for example:
The payload for an old collection event, generated by the garbage collector, would be the heap size before and after the collection.
The payload of an event to signal that a thread has been blocked by a lock would be the thread ID of the lock holder.
In addition to name and time stamp, most events also have information on the thread in which it occurred, the stack trace at the time the event was captured, and the duration of the event. All time stamps in JRockit Flight Recorder have nanosecond precision.
Requestable events are events that the recording engine can poll with a certain frequency. CPU Load Sample is an example for requestable event. You can configure the recording engine to poll for this event once every second.
By using the information available in an event, the JRockit Flight Recorder UI can reconstruct in detail what happened during program execution.
For a complete list of events, see Appendix C, "Events".
JRockit Flight Recorder is designed to keep its overhead as low as possible. When default settings are used, both internal testing and customer environments indicate that performance impact is less than one percent (< 1%). This percentage varies on the application and is sometimes significantly low.
JRockit Flight Recorder monitors the running system at an extremely high level of detail. This produces an enormous amount of data that JRockit Flight Recorder can handle. JRockit Flight Recorder filters data as early as possible to maintain low overhead. This is done in two different ways:
By limiting the type of events that are actually captured. You can control this information when you start the recording (for more information, see Chapter 3, "Starting the Flight Recorder").
By recording only those events with durations exceeding a certain threshold. In most cases, very short events are not of any interest and can be discarded. This effectively limits the amount of data JRockit Flight Recorder must handle. If you want to capture more data, you can change the threshold .
JRockit Flight Recorder does not write events to disk immediately, as they occur. Instead, it stores data in a hierarchy of in-memory buffers and then moves the data to the disk when the buffers are full. Initially, JRockit Flight Recorder run time puts the event data in thread-local buffers, eliminating the need to synchronize between threads for every event, which greatly improves throughput. Once a thread-local buffer has been filled, the data is transferred to a global buffer. When this happens, synchronization is necessary between threads but, because different thread-local buffers fill up at different rates, lock contention is rare. Eventually, the global buffer also runs out of space and the contents in the buffer are written to the disk. Writing to the disk is expensive and you must ensure that it happens as seldom as possible. Writing to disk files produces files in a proprietary, binary format that is extremely compact but also efficient for the applications to read and write.
You can configure JRockit Flight Recorder so that it does not write any data to disk. In this mode, the global buffer acts as a circular buffer and the oldest data is dropped when the buffer is full. This very low-overhead operating mode still collects all the vital data necessary for root-cause problem analysis. Because the most recent data is always available in the global buffer, it can be written to disk on demand whenever operations or surveillance systems detect a problem.
The Flight Recorder will generate special garbage collections whenever it makes a recording, which will appear as JFR Heap Block Statistics or JFR Class Statistics on the Garbage Collection Data section of the verbose output (that is, run with -Xverbose:gc=debug); for example:
[DEBUG][memory ] [OC#1] GC reason: Artificial, description: JFR Heap Block Statistics.