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

David Holmes dholmes at openjdk.org
Mon Oct 17 02:16:21 UTC 2022


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 am still not happy about this approach. JFR is written in Java and so triggers numerous events that are defined for Java code - that is a simple consequence of implementing it in Java. If there is to be filtering of events that originate from JFR Java code then there should be a general purpose filtering mechanism available to say "exclude JFR code" or "include JFR code" as desired. And to me the filtering mechanism should reside in the event commit code inside the JFR code not in the event-posting code in the shared components of the VM.

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

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


More information about the hotspot-jfr-dev mailing list