Currently there is no easy way to get the accumulative CPU time spent on GC activities. While e.g. G1 indeed samples GC time on each cycle, these numbers will be incorrect if GC cycle frequency is high, which is the case of multiples close to the minimum heap. The numbers are incorrect since we rely on the kernel to update the underlying values which only happens so often. Additionally since the precision is on the millisecond level it is also possible to observe cycles where we approximate the GC CPU time to 0, e.g.

[1.603s][info][gc,cpu] GC(60) User=0.00s Sys=0.00s Real=0.00s
[1.642s][info][gc,cpu] GC(61) User=0.00s Sys=0.00s Real=0.00s
[1.680s][info][gc,cpu] GC(62) User=0.00s Sys=0.00s Real=0.00s
[1.682s][info][gc,cpu] GC(63) User=0.00s Sys=0.00s Real=0.00s
[1.682s][info][gc,cpu] GC(63) User=0.00s Sys=0.00s Real=0.00s

This leads to inaccurate accumulative GC CPU time as error delta adds up.
We could fetch CPU time for GC related threads upon VM exit. This will assist a user/developer to understand the CPU cost for GC and may aid users setting a heap size.

JDK-8315149 introduced thread CPU time sampling in the VM thread on completed operation. This patch will add a conditional thread CPU time sampling for GC related VM operations before executing an operation to be able to measure the CPU time. This will allow us to account for e.g. Serial that only uses the VM thread, as-well as improving accounting for other GCs.