RFR: 8342818: Implement CPU Time Profiling for JFR

[Johannes Bechberger]

On Sat, 21 Sep 2024 12:44:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > The queue size is pre-computed to a large value that shouldn't lead to many dropped samples. I don't think that making the queue size settable is really useful. Please ignore, therefore, my mentioning of the queue size for throttling; the real throttling is by setting the interval. There is no other way that is also understandable by the user.
> 
> Recording files could be filled with CPU Time Sample events, flushing out important data, making the feature not usable for continuous profiling. We can't demand that users set a period every time they use JFR.

That is a valid point, so I see three options:

1. The event is experimental and mostly meant for profiling. So we might just ignore it, till we see any problems and don't fix problems before they arise.
2. We replace `period` with a `rate` property which states the maximum number of emitted CPUTimeSample events per second. We then use the rate to compute the interval internally as `period=(number of cores) / rate`. This alleviates the issues with having to set the interval every time to not get swamped by events. As an example, the standard rate in the profiling configuration could be `500 events/second` which produces at maximum the same number of events as the current JFR sampler (assuming >= 5 cores). This rate would result in a period of 10ms on a 5 core machine and 20ms on a 10 core machine. This effectively allows us to use the feature in continuous profiling.
3. Combine the period setting and the rate setting. We take the rate as the maximum rate, calculating the period as `period=max(user-period, (number of cores) / rate)`. This has the advantage of effectively having a similar as the current JFR sampler, by adding a lower bound for the interval.

Personally, I would the 3. option, because it should be least surprising to the users of the existing JFR sampler.
I would suggest calling the rate property `maxRate` and setting the following values in the configurations.

configuration | interval | maxRate
------------- | ------- | ---------
default.jfc      | 20ms   | 500 events/second
profile.jfc       | 10ms   | 1000  events/second

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

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2366897901