On Thu, 2 Nov 2023 01:20:59 GMT, Jonathan Joo <j...@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
