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

[Joakim Nordström]

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

I'm realizing that the monitor class isn't available elsewhere; it is in objectMonitor.cpp, and passed to private members in the `JavaObjectMonitorEvent`, which in turn is generated. The only possibility I see to moving the logic away from objectMonitor.cpp is to change how the event's classes are generated. Either by adding getter to certain members (in this case something like `get_monitorClass `to `JavaObjectMonitorEvent`), or trying to shoehorn the `is_excluded` method into the generated `JavaObjectMonitorEvent`. Neither of these approaches would I say are even worth considering, and they'd also still introduce overhead.

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

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