JEP draft: JFR Event Streaming

OwnerErik Gahlin
TypeFeature
ScopeJDK
StatusDraft
Componenthotspot / jfr
Discussionhotspot dash jfr dash dev at openjdk dot java dot net
EffortM
DurationS
Reviewed byKaren Kinnear, Mikael Vidstedt
Endorsed byMikael Vidstedt
Created2017/07/11 19:20
Updated2019/01/08 23:23
Issue8184193

Summary

Expose Flight Recorder data for continuous monitoring.

Goals

Non-Goals

Motivation

The HotSpot VM emits more than 500 data points using JFR, most of them not available through other means besides parsing log files.

To consume the data today, a user must start a recording, stop it, dump the contents to disk and parse the recording file. This works well for application profiling, where typically at least a minute of data is being recorded at a time, but not for monitoring purposes. An example of monitoring usage is a dashboard which displays dynamic updates to the data.

There is overhead associated with creating a recording, such as:

If there were a way to read data being recorded from the disk repository without creating a new recording file, much of the overhead could be avoided.

Description

The proposal is to provide an API with which users can subscribe to events asynchronously.

The following code snippet is a conceptual illustration for how such an API might look. It shows how to print all classes that threads have blocked on for more than 10 ms. If a consumer is not able to keep up, events will be dropped after 600 seconds.

EventStream.start("jdk.javaMonitorEnter", "threshold", "10 ms")
     .maxAge(Duration.ofSeconds(600)
     .consume(event -> System.out.println(e.getClass("monitorClass"));

This creates a recording and at a given interval, perhaps once every two seconds, events stored in memory and thread local buffers will be flushed to the disk repository. A separate thread parses the most recent file, up to the point in which data has been written, and pushes the events to the consumers. It's an open question how to handle flow control with multiple subscribers, but perhaps java.util.concurrent.Flow could be used.

Alternatives

JMX notifications provide means for the JDK and third party applications to expose information for continuous monitoring. There are however drawbacks that make JMX unsuited for the purpose of this JEP.

Testing

Risks and Assumptions