RFR: 8365611: Throttle any JFR event

[Thomas Stuefe]

On Mon, 18 Aug 2025 10:37:10 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> This patch prepares the way to throttle any JFR event, not only the three events for which we hard-code throttlers. It also cleans up the throttler code and replaces the switch construct with a lookup table.
>> 
>> The patch does not yet enable throttling for any other event, since that may be a contentious move, and I would like for this patch to go in without too much fuss. So I did not make any new events "throttleble".
>> 
>> If it turns out to be non-contentious, I am fine with just enabling throttling capability for all events.
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 117:
> 
>> 115: 
>> 116: JfrEventThrottler* JfrEventThrottler::create_throttler(JfrEventId id) {
>> 117:   JfrEventThrottler* p = new JfrEventThrottler(id);
> 
> JfrEventThrottler is a JfrAdaptiveSampler that utilizes the JfrCHeapObj allocator, which can return nullptr during JFR initialization.

Are you sure? 

..

Ah, I see it now. You end up calling the nothrow variant of `CHeapObjBase::operator new`. And treat malloc OOMs during initialization as non-fatal, runtime malloc OOMs as fatal.

May I ask why you bother? Is the memory footprint of JFR really so high as to make this distinction worthwhile? (As in "if JVM does not come up with JFR, the footprint without JFR will be so much lower that it is worth trying"?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26801#discussion_r2282403845