RFR: 8342818: Implement CPU Time Profiling for JFR

[Erik Gahlin]

On Sun, 22 Sep 2024 18:05:27 GMT, Johannes Bechberger <jbechberger 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

How does maxRate differs from today's "throttle" and why is an additional setting needed?

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

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