RFR: 8351142: Add JFR monitor deflation and statistics events [v4]

[Aleksey Shipilev]

On Wed, 12 Mar 2025 13:42:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I think we should only add such metrics where there is a strong justification to do so, and where a calculated value would have failed to solve the underlying problem

Right, makes sense. Let's recap.

The underlying reason for providing peak statistics is to track the population of object monitors without computing it from individual inflate/deflate events. Since it is periodic, it run into sampling bias. The sampling bias works not only for peaks, but also for dips, so I would guess a fuller solution would be indeed to add `min/max` counters, _if_ we wanted to avoid the bias. But, I think this goes too far. 

We want to replace one of the `ObjectMonitor` counters that counts the instantaneous monitor population. It does not really report peak/max. I can see that OM code might want to stop tracking `max`, but JFR event would force its hand, if we start reporting it.

So, thinking that _adding_ a new field into JFR event is easier than yanking the unnecessary/bad one, I think we should be conservative and just report the instantaneous monitor population. If we find it is insufficient, then we can talk about extending the event. Sounds good?

Dropped `peakCount` from this PR in new version. Take a look again, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/23900#issuecomment-2718008992