Container-aware heap sizing for OpenJDK

[Volker Simonis]

On Wed, Oct 19, 2022 at 7:15 PM Man Cao <manc at google.com> wrote:
>
> Hi Volker,
>
> Yes, we are aware of "sun.gc.collector.{0,1,2}.time", and they only account for pause time.
> Accounting for only pause time does not accurately measure GC overhead for collectors with a large portion of concurrent work.
> This is also the reason why heuristics based on -XX:GCTimeRatio are broken for G1. https://mail.openjdk.org/pipermail/hotspot-gc-dev/2021-May/035241.html has a related discussion.
>
> Yes, the CPU time metric sums up CPU time from all parallel GC worker threads and concurrent GC threads.
> I just found https://bugs.openjdk.org/browse/JDK-8291753 which exports CPU time via JFR events. However, it seems to only account for CPU time spent during pauses, which does not cover all concurrent work. I'll do more digging and follow up when I create an RFE.
>

I think you're right. But we also have the
sun.management.HotspotInternal MBean which already exports the CPU
time for all non-Java threads through the InternalThreadCpuTimes
attribute of the sun.management:type=HotspotThreading MBean.
Alternatively, we can also get the CPU time of all GC threads from
/proc/<pid>/task<thread-id>/stat (by summing up the times from all
threads which contain GC/G1 in their name (i.e.
/proc/<pid>/task/<tid>/comm)). This is also what
InternalThreadCpuTimes is using to get the the CPU times of non-Java
threads if pthread_getcpuclockid() is not available.

So the question is if it is necessarily to export the CPU time of GC
threads through hsperf at all, if we can already get this information
from the /proc file system?

> -Man