RFR: 8364638: Refactor and make accumulated GC CPU time code generic [v2]

[Jonas Norlinder]

> Hi all,
> 
> This PR refactors the newly added GC CPU time code from [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110).
> 
> As a stepping-stone to enable consolidation of CPU time tracking in e.g. hsperf counters and GCTraceCPUTime and to have a unified interface for tracking CPU time of various components in Hotspot this code can be refactored. This PR introduces a new interface to retrieve CPU time for various Hotspot components and it currently supports:
> 
> CPUTimeUsage::GC::total() // the sum of gc_threads(), vm_thread(), stringdedup()
> 
> CPUTimeUsage::GC::gc_threads()
> CPUTimeUsage::GC::vm_thread()
> CPUTimeUsage::GC::stringdedup()
> 
> CPUTimeUsage::Runtime::vm_thread()
> 
> 
> I moved `CPUTimeUsage` to `src/hotspot/share/services` since it seemed fitting as it housed similar performance tracking code like `RuntimeService`, as this is no longer a class that is only specific to GC.
> 
> I also made a minor improvement in the CPU time logging during exit. Since `CPUTimeUsage` supports more components than just GC I changed the logging flag to from `gc,cpu` to `cpu` and created a detailed table:
> 
> 
> [12.517s][info][cpu] === CPU time Statistics =============================================================
> [12.517s][info][cpu]                                                                             CPUs
> [12.517s][info][cpu]                                                                s       %  utilized
> [12.517s][info][cpu]    Process
> [12.517s][info][cpu]      Total                                              175.7628  100.00      14.0
> [12.517s][info][cpu]      VM Thread                                            7.0000    3.98       0.6
> [12.517s][info][cpu]      Garbage Collection                                  72.0000   40.96       5.8
> [12.517s][info][cpu]        GC Threads                                        70.0000   39.83       5.6
> [12.517s][info][cpu]        VM Thread                                          1.0000    0.57       0.1
> [12.518s][info][cpu]        String Deduplication                               0.0000    0.00       0.0
> [12.518s][info][cpu] =====================================================================================
> 
> 
> Additionally, if CPU time retrieval fails it should not be the caller's responsibility to log warnings as this would bloat the code unnecessarily. I've noticed that `os` does log a warning for some methods if they fail so I continued on this path.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Remove assert which may not hold in tests that exists very fast
  
  It takes some time before the OS updates the underlying counters so process CPU time may be out of sync with regards to magnitude order compared to thread CPU time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26621/files
  - new: https://git.openjdk.org/jdk/pull/26621/files/4f74c2bd..6a6e3996

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26621&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26621.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26621/head:pull/26621

PR: https://git.openjdk.org/jdk/pull/26621