RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]

[Erik Gahlin]

On Thu, 5 Jun 2025 09:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the mistakenly added file.
>>  - Fix whitespace
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 845:
> 
>> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
>> 844:       <setting name="stackTrace">true</setting>
>> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>
> 
> What was used to propose 100/s as the default and 300/s in profile.jfc?  Just curious if there was a benchmark or test to see the overhead.

It's hard to benchmark since it depends on the application, but we have used 150 events / second for the Object Allocation Sample event without complaints. If you divide one second by 20 ms, the previous threshold, you end up with at most 50 events / second per thread. That said, I think few applications actually have socket read/write around 20-25 ms, so I don't think we should draw too many conclusions from that.

Another way of thinking about it is that the cost of walking maximum 64 stack frames is roughly 5000 ns, so we end up with 100 * 5000 = 500 000 ns or 0.05% of CPU usage. There is also the cost of sampling, and that's why I put in the 1 ms threshold, which puts an upper bound of 1000 sampling attempts per thread.

For profile, I used the same value as Object Allocation Sample.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128549389