RFR: 8247471: Enhance CPU load events with the actual elapsed CPU time

Jaroslav Bachorik jbachorik at openjdk.java.net
Thu Jun 10 08:42:17 UTC 2021


On Wed, 19 May 2021 16:41:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> A continuation of an RFR thread started last year - https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-June/001533.html
>> 
>> This change adds the raw CPU time value to CPU load events (per-thread and per-process as well). 
>> The CPU time value is already known and used to calculate the load so adding it to the events does not incur any extra overhead while making it much easier for the end users to eg. aggregate and compare the active execution time per time period without the detailed knowledge how JFR computes and normalizes the CPU load.
>
> It would be nice to have this for JDK 17, but I guess we are stuck on how the elapsed difference should be reported.
> 
> I would like to avoid using the duration field, because it's not used for any other event that samples data periodically. We could be opening a can of worms.
> 
> If we are going to measure execution time since the last sample, I think we should make it clear in the description, i.e "Elapsed JVM User CPU Time since last sample". While not optimal, a separate field or duration, could be added in a later release, even though it could lead to bugs, if using JFR on an old release where duration is 0 s.

@egahlin thanks for the review!
But I decided to close this PR since I was not able to get comparable behaviour across different platforms - namely the windows implementation was either providing inconsistent CPU time and CPU load values, due to them being retrieved from disparate sources, or when I used only the common source the precision of the CPU load value dropped significantly (the CPU time granularity on windows in somewhere in range of 10-100ms AFAIK and this was affecting the CPU load now computed from CPU time).

Given these problems and no good solution (even after consulting the problem with a few people skilled in Windows architecture) I decided it was better not to pursue this PR further.

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

PR: https://git.openjdk.java.net/jdk/pull/2186


More information about the hotspot-jfr-dev mailing list