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

[David Holmes]

On Mon, 17 Oct 2022 12:08:01 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> 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.

@mgronlun my request is that this filtering be done inside the commit logic by the JFR code, not at the site where the event is generated - ie this internal-jfr-event filtering is internalized into the JFR code.

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

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