RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v33]

[Albert Mingkun Yang]

On Thu, 26 Oct 2023 21:01:53 GMT, Jonathan Joo <jjoo at openjdk.org> wrote:

>> 8315149: Add hsperf counters for CPU time of internal GC threads
>
> Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove StringDedup from GC thread list

> For tools like AHS that reads these CPU hsperf counters, they could read these CPU data every 1 to 5 seconds.

Okay, these counters can be accessed frequently, but is it necessary for them to provide up-to-date information on every access? If not, what level of delay is acceptable? I assume this depends on how often AHS resizes the heap. (In the Parallel case, I believe the counters can be outdated for the duration of the full-gc.)

My primary concern is that the change in G1 is too intrusive -- the logic for tracking/collecting thread-CPU is scattered in many places. Additionally, the situation is expected to worsen in the near future, based on the statement "I can create a separate RFE to make it update more frequently..."

Also, why isn't `G1ServiceThread` part of the change? I would expect all subclasses of `ConcurrentGCThread` to be taken into account. Is this omission intentional?

Finally, thread-CPU time is something tracked at the OS level, so it's a bit odd that one has to instrument the VM to get that information.

> - Looking into the `/proc/` method, it also is not super intuitive as to which value corresponds to GC time, and it might be difficult to reliably identify all PIDs of the relevant GC threads.

According to https://man7.org/linux/man-pages/man5/proc.5.html, "(14) utime" + "(15) stime  %lu" == thread-cpu-time. `cat /proc/<java-pid>/task/*/stat` lists all VM internal threads, including GC, JIT, and etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/15082#issuecomment-1782969884