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

[Stefan Johansson]

On Thu, 2 Nov 2023 01:20:59 GMT, Jonathan Joo <jjoo at openjdk.org> wrote:

> Could you elaborate a bit on what you were thinking of here? If we are assuming something like a thread that updates all other threads, I think this implementation could get a bit complicated.
> 
> There are two main issues that we can see with a generic thread approach:
> 
>     1. We would have to figure out how often to pull metrics from the various gc threads from the central thread, and possibly determine this frequency separately for every thread. Instead with our current implementation, we can manually trigger publishes based on when the GC thread is done doing work.
> 
>     2. We would still need to tag each thread we want to track somewhere, and keep track of a mapping from thread to its counter name, etc. which doesn't seem to simplify things too much. (I imagine we will still need to touch numerous files to "tag" each thread with whether we want to track it or not?)

I agree, I was not thinking about having a separate thread, more about trying to group this information in a way that it would be easier, for example, to provide periodic JFR events for the CPU times collected. Having something like a `CollectorCPUTimeCounters` (we already have `CollectorCounters`). Such a class could keep the different counters making it easier to get an overview of which CPU time counters are present. But this would also require a mapping between thread and counter (but it might be as simple as having an enum). 

I played around a bit instead of trying to explain what I mean and this is not very polished, but I was thinking something like this: 
https://github.com/openjdk/jdk/compare/pr/15082...kstefanj:jdk:pull/15082-idea

What do you think? This way we don't add things to `CollectedHeap` as well, which is usually good unless really needed.

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

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