Add garbage collector info to process info contributor

[jonatan-ivanov]

Since GC algorithms can be selected by JVM ergonomics, it might not be trivial to know them since the decision usually depends on the available processors and the available memory. Especially in (containerized) environments where resource usage can be isolated (for example using control groups) or not necessarily trivial to discover.

Example outputs (click to reveal)

BellSoft Liberica 23+38

-XX:+UseSerialGC

"garbageCollectors": [
    {
        "name": "Copy",
        "collectionCount": 0
    },
    {
        "name": "MarkSweepCompact",
        "collectionCount": 2
    }
]

-XX:+UseParallelGC

"garbageCollectors": [
    {
        "name": "PS MarkSweep",
        "collectionCount": 2
    },
    {
        "name": "PS Scavenge",
        "collectionCount": 0
    }
]

-XX:+UseG1GC

"garbageCollectors": [
    {
        "name": "G1 Young Generation",
        "collectionCount": 8
    },
    {
        "name": "G1 Concurrent GC",
        "collectionCount": 4
    },
    {
        "name": "G1 Old Generation",
        "collectionCount": 0
    }
]

-XX:+UseZGC (Generational ZGC)

"garbageCollectors": [
    {
        "name": "ZGC Minor Cycles",
        "collectionCount": 0
    },
    {
        "name": "ZGC Minor Pauses",
        "collectionCount": 0
    },
    {
        "name": "ZGC Major Cycles",
        "collectionCount": 2
    },
    {
        "name": "ZGC Major Pauses",
        "collectionCount": 10
    }
]

-XX:+UseZGC -XX:-ZGenerational (Non-Generational ZGC)

"garbageCollectors": [
    {
        "name": "ZGC Cycles",
        "collectionCount": 2
    },
    {
        "name": "ZGC Pauses",
        "collectionCount": 6
    }
]

-XX:+UseShenandoahGC

"garbageCollectors": [
    {
        "name": "Shenandoah Pauses",
        "collectionCount": 8
    },
    {
        "name": "Shenandoah Cycles",
        "collectionCount": 2
    }
]

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC (YOLO)

"garbageCollectors": [
    {
        "name": "Epsilon Heap",
        "collectionCount": 0
    }
]

No CMS since it was removed in Java 14 and no Generational Shenandoah since it will be introduced in Java 24.

IBM Semeru 23.0.2+7, OpenJ9 0.49.0

-Xgcpolicy:balanced

"garbageCollectors": [
    {
        "name": "partial gc",
        "collectionCount": 0
    },
    {
        "name": "global garbage collect",
        "collectionCount": 0
    }
]

-Xgc:concurrentScavenge

"garbageCollectors": [
    {
        "name": "scavenge",
        "collectionCount": 10
    },
    {
        "name": "global",
        "collectionCount": 0
    }
]

BellSoft Liberica NIK 23.0.0-1

GraalVM Community 17.0.7+7-LTS, native-image (SubstrateVM), G1 GC

"garbageCollectors": [
    {
        "name": "young generation scavenger",
        "collectionCount": 0
    },
    {
        "name": "complete scavenger",
        "collectionCount": 0
    }
]

[mhalbritter]

Thanks @jonatan-ivanov ! On the GarbageCollectorMXBean there's also getCollectionTime. Would it make sense to expose that, too?

And we already expose a memory object in the JSON. Would it make sense to move the garbageCollectors under memory, too?

[jonatan-ivanov]

getCollectionTime returns the cumulative collection time (since the jvm start) which I think would be inconvenient watching here, I would use a metrics backend for that one. But if somebody has a good use-case, it's totally ok to add.

Btw, I only wanted to have the name of the collectors first but then I added collection count so that you can verify which GC (minor, full) was triggered if any (e.g.: you called System.gc() or hit "run GC" in jconsole and then you can check the endpoint if the counter is incremented or not).

The place of this is a great question, I think it makes sense to place it under memory, I can make the change.

[mhalbritter]

Thanks @jonatan-ivanov !