[External] : Re: RFD: Throttling Support for Java-Level JFR Events

[Erik Gahlin]

________________________________


  *   Yes. However, not every user likes to implement a throttling mechanism by themselves.
True, but it doesn't necessarily need to come with the JDK. It can be implemented as a third-party library where many different throttling classes can exist.

IMO, the main benefit of a standardized throttling mechanism is that JMC, or other tools, knows the mechanics, so they can provide appropriate visualization. Users need to know if every event is displayed, or only one out of a hundred.

  *   The specific implementation method can be discussed further, if this feature is indeed necessary to be implemented at the JDK layer.
What makes throttling tricky is that there are so many ways to do it. For example, how should an event with a threshold be throttled? All events? Only those above the threshold? Only those below the threshold? Configurable?

I can see how a throttling mechanism similar to jdk.ObjectAllocation can be useful for direct memory allocation. It may make sense to reuse what's available in native, if feasible. The native implementation has been designed so it can easily be extended for other events.

Not sure how the RPC events work, but sometimes it can be more useful to sample per request/transaction and get all events for that request/transaction, rather than throttle per event type.

Erik
------------------------------------------------------------------
From:Erik Gahlin <erik.gahlin at oracle.com>
Send Time:2023年11月16日(星期四) 05:01
To:hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>; 董登辉(卓昂) <denghui.ddh at alibaba-inc.com>
Subject:Re: RFD: Throttling Support for Java-Level JFR Events

Hi Denghui,

It's been considered it, but we like to see a few real use cases before adding it.

Do you see a use case for JDK events or for user defined events?

If user defined, could you describe the events?

The JFR API allows users to create their own throttling mechanism using the SettingControl class.

We are aware of that exception and I/O events could potentially benefit from throttling, but not sure the mechanism should work similar to native events. There is also visualization aspects to take into consideration. JMC would need to be updated so it can differentiate between outliers or throttling.

Thanks,
Erik

________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Denghui Dong <denghui.ddh at alibaba-inc.com>
Sent: Wednesday, November 15, 2023 9:20 AM
To: hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
Subject: RFD: Throttling Support for Java-Level JFR Events

Hi team,

We have observed increased adoption of JFR for information collection within our internal applications and frameworks.

However, we've encountered situations where critical events occur frequently, prompting us to explore
the possibility of introducing a throttling mechanism for Java-level events.

Currently, my understanding is that throttling is exclusively supported for native event ObjectAllocationSample.
Should we consider extending this feature to Java-level events?

Thanks,
Denghui Dong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20231120/8586ccce/attachment-0001.htm>