JvmMonitor: Handle more generation and collector scenarios.

[gianm]

ZGC on Java 11 only has a generation 1 (there is no 0). This causes
a NullPointerException when trying to extract the spacesCount for
generation 0. In addition, ZGC on Java 15 has a collector number 2
but no spaces in generation 2, which breaks the assumption that
collectors always have same-numbered spaces.

This patch adjusts things to be more robust, enabling the JvmMonitor
to work properly for ZGC on both Java 11 and 15.

[clintropolis]

👍

[FrankChen021]

I notice that we're using the JStatData APIs provided in the org.gridkit.lab dependency to get metrics of GC. And this lib requires an additional JVM argument --add-exports=java.base/jdk.internal.perf=ALL-UNNAMED to enable the counters because it uses the APIs inside the tools.jar to get the counters.

The JDK itself provides public management API to allow us to access these counters.

• For GC metrics, we can use java.lang.management.GarbageCollectorMXBean to get the metrics. Here's a reference implementation from my personal repo: https://github.com/FrankChen021/bithon/blob/master/agent/agent-plugins/jvm/src/main/java/org/bithon/agent/plugin/jvm/gc/GcMetricCollector.java

• For the GC memory spaces, we can use the ManagementFactory.getMemoryPoolMXBeans() to get the objects that hold the memory size of different GC memory spaces.

I think we can use these APIs to replace the old one so that we:

• can drop the additional JVM argument requirement on JDK 11 and above
• don't need to change our code to adapt the collector and space names.

BTW, I'm not saying we need to do this in this PR.

[gianm]

@FrankChen021 That sounds like it would be an excellent enhancement. I'm not sure why the current code uses JStatData instead of the MXBeans. IMO we could merge this patch now, and then switch to MXBeans when someone has the opportunity to write & test a new version of the JvmMonitor.