JDK-8222736 : Need more granularity to know when to spend time on JFR computations needed by specific events
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 13
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2019-04-18
  • Updated: 2020-02-11
  • Resolved: 2019-11-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Relates :  
Relates :  
Description
While working on JDK-8185525 and JDK-8211331 a question raised about the mechanism one can use to figure out whether we need to keep collecting relevant statistics for JFR events.

Currently we have:

- JFR_ONLY() macro
- Jfr::is_recording()
- Jfr::is_enabled()

but I don't think that these give us the required granularity.

Imagine a computation needed by EventA. With JFR compiled in, and the recording ON and enabled, we still can not be 100% sure whether the EventA itself is being recorded or not, so we have currently no choice, but to collect the data for EventA, even when that particular event is not actually being recorded.

We need something like Jfr::is_on(EventA)

With JFR asking for more and more events, without such granularity we will be waisting resources and impacting the entire JFR framework by ever so slightly slowing it down as we continue to add new events.
Comments
In the general case there is: if (EventA::is_enabled()) { .... } and EventA a; if (a.should_commit()) { } If Hotspot is built without JFR, the above will turn into false and the compiler will eliminate the guarded code path. If it is build with JFR, it is a boolean check, which branch prediction will typically detect. Not sure if it applies to your use case, since you calculate a rate. Some special logic may be needed, I don't know.
18-04-2019