On Thu, 26 Oct 2023 21:01:53 GMT, Jonathan Joo <j...@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
