New throttle setting

[Marcus Hirt]

Hi Erik,

Thanks for the update!

One thing that is making the jdk.ObjectAllocationSample event particularly useful is that there is information about the distance between the samples  (the amount of memory allocated), meaning that there is a weight associated with each sample, helping to properly gauge the contribution associated with that sample relative other samples. Is there a plan to do extend these throttled events in a similar fashion? For example, JavaExceptionThrow could indicate the number of exceptions since the last sampled event, and the I/O events could report the number of bytes read/written since the previous sample. 

Also, do you have a sense of when we’ll know whether this will land in JDK 25? Since JDK 25 is targeted for September (if I remember correctly), and JMC 10 isn’t expected until October 2026 (https://wiki.openjdk.org/display/jmc/Releases), we may want to consider planning for an additional JMC 9.x if there is work required to support the changes in JDK 25.

Kind regards,
Marcus

--- 
From: jmc-dev <jmc-dev-retn at openjdk.org> On Behalf Of Erik Gahlin
Sent: Wednesday, 21 May 2025 18:06
To: jmc-dev at openjdk.org
Subject: New throttle setting

Hello,

I'm planning to add rate-limited sampling to Java events. It will work similarly to the JVM event jdk.ObjectAllocationSample today. Hopefully, it will make it into JDK 25. I mention this because it may have an impact on JMC. The following events will get a new setting called "throttle", where a rate can be specified.

 - jdk.SocketRead
 - jdk.SocketWrite
 - jdk.FileRead
 - jdk.FileWrite
 - jdk.JavaExceptionThrow

The filtering will happen after the threshold setting has been applied. The purpose of the new setting is to have more events enabled by default. The threshold for I/O events today is 20 ms, which is rather high to avoid high CPU usage and buffers being flooded in pathological applications.

It may be possible to set the threshold to 0 ms for I/O events when rate-limited sampling is in use in the default configuration, but I'm worried about regressions, so the current plan is to set the threshold to 1 ms and throttle to 300/s. For the profile configuration, the threshold will be set to 0 ms and the rate increased to 600/s.

The jdk.JavaErrorThrow event will continue to work as before.

Long-term, the plan is to sample exceptions per allocation site and remove jdk.JavaErrorThrow. The implementation is more complicated, but  I think this will be an improvement for now.

For JDK 25, the plan is to add control options for method timing and tracing, as part of JEP 520: JFR Method Timing & Tracing. I noticed that the new options will fill the recording wizard, so not all options are visible. The dialog is too small. If we get throttling for I/O and exceptions into JDK 25, the exception combobox and I/O threshold text box can be removed, so it will be fine without any code changes to JMC.

If you have questions, please let me know, either here or on the JMC Slack channel.

Thanks,
Erik