![]() Previous |
![]() Next |
Figure: Java Flight Recorder Data Flow shows how data flows through the JFR.
Data is sent to the Flight Recorder recorder by the JVM (through internal APIs) and by the Java application (through the Flight Recorder APIs). The Flight Recorder runtime stores this data in small thread-local buffers that are flushed to a global in-memory buffer when they are full. When the Flight Recorder is running in a persistent storage mode, data in the global in-memory buffer(s) is written to disk when those buffers are full.
Information overlap between the various buffers will not occur. A particular chunk of data is available either in memory or on disk, but never both. This has the following implications:
Data not yet flushed to a disk buffer will not be available in the event of a power failure.
A JVM crash can result in some data being available in the core file (that is, the in-memory buffer) and some in the disk buffer. The Flight Recorder provides no capability to merge such buffers (an advanced client program or tool might, but that's outside of the scope of this version).
There may be a small delay before data inserted into the Flight Recorder is available to consumers (for example, because it has to be moved to a different buffer before it can be made visible).
The data in the JFR file may not be in time sequential order as the data is collected in chunks from several thread buffers.
In some extreme cases, HotSpot will drop events order to not block the JVM from running. Any data that can not be written fast enough to disk will be discarded. When this happens, the recording file will include information on which time period was affected. This information will also be logged to the logging facility of the JVM.