Periodic events and event streaming introduced Thread.sleep(..) or Object.wait(...) into the JFR code, but we have received feedback that the JavaMonitorWait event is adding noise and/or unnecessary data into recordings (JDK-8286707).
To prevent this, a class with a known name was introduced that the JavaMonitorWait event ignores. If Java code waits on an object of that class, an event will not be emitted. The class was first used for periodic events and then later generalized (HiddenWait) and used for the epoch shift sleep before rotating (JDK-8304732). Note, the class is only accessible by JDK classes.
The change consists of replace all use of Thread.sleep(..) in JFR with convenience methods that wait on an object of type HiddenClass. If possible, reusing the HiddenWait instance to reduce allocation.
An argument can be made that Thread.sleep(...) or Object.wait(...) used by JFR should be visible, but if such requests arise, we may consider adding an option to override the current behavior. This change will make such a future option consistent, so the change still have value.
To prevent this, a class with a known name was introduced that the JavaMonitorWait event ignores. If Java code waits on an object of that class, an event will not be emitted. The class was first used for periodic events and then later generalized (HiddenWait) and used for the epoch shift sleep before rotating (
The change consists of replace all use of Thread.sleep(..) in JFR with convenience methods that wait on an object of type HiddenClass. If possible, reusing the HiddenWait instance to reduce allocation.
An argument can be made that Thread.sleep(...) or Object.wait(...) used by JFR should be visible, but if such requests arise, we may consider adding an option to override the current behavior. This change will make such a future option consistent, so the change still have value.
- links to
-
Commit(master) openjdk/jdk/e0fb9494
-
Review(master) openjdk/jdk/20075