Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8315149

Add hsperf counters for CPU time of internal GC threads

    XMLWordPrintable

Details

    • svc
    • b27

    Description

      There are a number of HsPerf counters that would be useful to track within the JVM to get a better understanding of where CPU time is spent when doing GC.

      More specifically, we should introduce counters that track the various CPU time spent in various phases of GC. For example, time spent in:

      - Parallel GC: CPU time consumed by parallel GC worker threads, updated after every stop-the-world collection.
      - G1 Concurrent Mark (Only available for G1): CPU time consumed by ConcurrentMark thread and concurrent GC worker threads, updated after concurrent root scan, concurrent mark, concurrent cleanup and at the end of a concurrent cycle.
      - G1 Concurrent Refine (Only available for G1): CPU time consumed by ConcurrentG1RefineThread threads, updated every time the main worker thread finishes its share of refinement work.
      - Concurrent String Dedupliation (Available with +UseStringDeduplication): CPU time consumed by concurrent string deduplication thread, updated every time it finishes processing pending deduplication work.
      - VM Thread Time: CPU time consumed by the VMThread, updated after executing every VM_Operation.


      For context, the value of these counters was discussed briefly in the context of Container-aware heap sizing: https://mail.openjdk.org/pipermail/hotspot-gc-dev/2022-October/040433.html



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

      Open Questions:

      1. Do we want to support these metrics for other GCs, given that the main use case for these counters are for Container-aware heap sizing, which is planned to only be supported for G1GC (for now)?
      - From Google's perspective, I suggest we focus on G1GC, and expand porting these metrics to other GCs if we find it to be useful. This PR has implemented the counters for G1 and ParallelGC.
      2. Is there is a better way to report these metrics besides hsperf counters (i.e. `sun.management.HotspotInternal` MBeans, JFR events, or parsing `/proc`)?
      - From Google's perspective, the work done with Container-aware heap sizing was done using these hsperf counters, so this would be the smoothest option for us to bring this project upstream without having to re-architect and re-validate our work. Thus, we strongly prefer this implementation.


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

      Update: the final hsperf counters added are:

      sun.threads.total_gc_cpu_time
      sun.threads.cpu_time.gc_parallel_workers
      sun.threads.cpu_time.gc_conc_mark
      sun.threads.cpu_time.gc_conc_refine
      sun.threads.cpu_time.gc_service
      sun.threads.cpu_time.vm
      sun.threads.cpu_time.conc_dedup

      Attachments

        Issue Links

          Activity

            People

              jjoo Jonathan Joo
              jjoo Jonathan Joo
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: