RFR: 8351146: JFR: Reconsider thresholds for monitor-related events

[Aleksey Shipilev]

On Tue, 4 Mar 2025 11:03:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are two issues with current thresholds for monitor-related events:
> 
>  1. The threshold for enter/wait is too high for practical use. @coleenp separately said during related CSR review that 5ms is more practical value: https://bugs.openjdk.org/browse/JDK-8348833?focusedId=14744853#comment-14744853 -- I think we should trim those even further.
>  
>  2. There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)), which should match inflations.
> 
> The PR changes `locking-threshold` default, so it affects a few other events as well. I am picking 1ms as the practical value that we usually deal with in production environments, as we chase down single-digit-ms latency hogs. I am open for suggestions about the values, though. Maybe `default.jfc` values should be higher?
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes

Understood, thanks for the context.

Would you agree to drop the threshold from `JavaMonitorInflate` event? That event does not involve actual locking, and so it is weird to have it with a time threshold. The event is disabled, so there should be no impact on default/profile configs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2700282019