RFR: 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events [v2]

[Markus Grönlund]

On Fri, 14 Oct 2022 08:52:11 GMT, Joakim Nordström <jnordstrom at openjdk.org> wrote:

>> Changed the JFR chunk rotation lock object to specific internal class. This allows that specific Object.wait() event to be skipped, thus not adding JFR internal noise to recordings. 
>> 
>> # Testing
>> - jdk_jfr
>
> Joakim Nordström has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Changed name to CHUNK_ROTATION_MONITOR and made some other rearrangements
>  - Changed name to CHUNK_ROTATION_MONITOR and made some other rearrangements
>  - Merge branch 'master' into JDK-8286707-jfr-dont-commit-jfr-internal-jdk-javamonitorwait-events
>  - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events
>  - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events
>  - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events
>  - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events

There exist a general exclusion/inclusion mechanism already. But it is an all-or-nothing proposition. This particular case is a thread that we can't exclude because it runs the periodic events, upon being notified. It is the notification mechanism to run the periodic events that trigger this large amount of unnecessary MonitorWait events. Even should we change it to some util.concurrent construct, we are only pushing the problem, because we might be instrumenting them later too. To work with the existing exclusion mechanism, the system would have to introduce an additional thread, which will be excluded, which only handles the notification, and then by some other means triggers another periodic thread (included) to run the periodic events.

-------------

PR: https://git.openjdk.org/jdk/pull/8883