Re: Extending ThreadCPULoadEvent functionality? (discussion)

Denghui Dong denghui.ddh at alibaba-inc.com
Wed May 13 02:16:51 UTC 2020


Hi Jaroslav,
(disclaimer: I am not a reviewer)
One comment:
We can judge if the thread is a java thread or not by the thread constant, so it's not necessary to add an extra attribute "isJava"

By the way, could we limit the amount of EventThreadCPULoad, like EventObjectCount? Because some applications have many threads,
but most of those threads are idle. And I think to add a new VM parameter like ObjectCountCutOffPercent is not a good way, we need a more general
solution.

Thanks,
Denghui Dong

------------------------------------------------------------------
From:Jaroslav Bachorík <jaroslav.bachorik at datadoghq.com>
Send Time:2020年5月13日(星期三) 00:54
To:hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
Subject:Extending ThreadCPULoadEvent functionality? (discussion)

Hello,

in its current form the ThreadCPULoadEvent converts the collected CPU
time into (estimated) CPU load and does this only for Java threads.

It would be extremely useful (at least to us in Datadog) to have
access to the raw CPU time which was used to calculate the load.
Although we can kind of reverse-engineer that from the wall time and
the reported number of CPUs it is awkward and in case of containerized
environments might not be very precise.
As for the thread cpu load events emitted for non-java thread - this
would be mostly useful for attributing the overall load to
java/non-java threads which in turn allows for making conclusion about
user load vs. the runtime load eg.

The idea proposed here is to capture the CPU time as an event
attribute and do that for both java and non-java thread,
distinguishing between them via another event attribute.

The code changes are very PoC - the code does what it is supposed to
do without causing any regressions but the actual implementation is
subject to change depending on the outcomes of this discussion.

Webrev: http://cr.openjdk.java.net/~jbachorik/jfr_cpu_time/webrev/

Thanks all for taking your time here!

Cheers,

-JB-


More information about the hotspot-jfr-dev mailing list