RFR: 8351187: Add JFR monitor notification event [v4]

[Aleksey Shipilev]

On Thu, 6 Mar 2025 19:39:45 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

> Generally, any event that cannot be enabled by default needs good motivations.

It is not like we cannot enable it by default. We just don't know yet what is the actual overhead of doing so. My initial thought was to not enable it by default to give us extra safety.

> Unsure if this event type carries enough weight. The JavaMonitorEvent already has a notified field

This event complements `Wait` event, giving the us novel capabilities. Capturing notifier thread in wait event gives us some info, but lacks the context for notification itself. For example, the stack trace for notification. Also -- and it could have been handy a few months back for actual performance work! -- new event allows us to estimate notify->wait latencies almost directly:


$ build/linux-x86_64-server-release/images/jdk/bin/java \
  -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps \
  -XX:StartFlightRecording=filename=latency.jfr,jdk.JavaMonitorNotify#enabled=true \
  NotifyWaitLatency.java


Sample event pair:


      "type": "jdk.JavaMonitorNotify", 
      "values": {
        "startTime": "2025-03-14T19:01:50.186277259+01:00", 
        "duration": "PT0.000000491S", 
        "notifiedCount": 1, 
        "address": 135954102752832

      "type": "jdk.JavaMonitorWait", 
      "values": {
        "startTime": "2025-03-14T19:01:50.086326997+01:00", 
        "duration": "PT0.099964319S", 
        "address": 135954102752832


The latency estimate is: .086326997s + .099964319s - .186277259s = .000014057s = 14.1us

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

PR Comment: https://git.openjdk.org/jdk/pull/23901#issuecomment-2725440464