RFR: 8351146: JFR: Reconsider thresholds for monitor-related events
Erik Gahlin
egahlin at openjdk.org
Wed Mar 5 20:32:56 UTC 2025
On Wed, 5 Mar 2025 09:01:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> 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 in `default.jfc`, so there should be no impact there. It is enabled in `profile.jfc`, but I believe inflations are self-limiting in realistic applications that do not churn the monitors. We can disable the `JavaMonitorInflate` event in `profile.jfc` if we want to be extra-safe. With current threshold it is effectively disabled anyway, I think.
I'm fine with removing the threshold if the duration is useless, but I would prefer to have the JavaMonitorInflate event disabled. Maybe it's OK to have it enabled, but I would need to look into it further before making a decision. The JavaMonitorInflate event would function well with adaptive rate-sampling. With an upper limit in place, we don't need to speculate about how often locks are inflated in a typical application.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23891#issuecomment-2701996669
More information about the hotspot-jfr-dev
mailing list