-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
None
There is a GC analysis tool called Garbagecat (https://github.com/mgm3746/garbagecat/tree/main) which operates on GC logs, and identifies performance issues and suggests potential solutions to these problems. This analysis is reminiscent of the JMC Automated Analysis, and it would be nice to see if some of their GC analysis could be brought over to JMC in the form of rules.
One particular analysis of interest is "Inverted Parallelism", which takes a look at the sys+usr time of a parallel GC and compares it against the real (wall) time. If the parallelism is low, this can indicate that the parallel gc is operating at the efficiency of serial gc, and something could be improved. GC CPU time is a recent addition to the JFR event space, and was included in JDK20+ as of: https://bugs.openjdk.org/browse/JDK-8291753.
For example, the actual warning message that Garbagecat produces looks like this:
There is evidence of inverted parallelism. With parallel (multi-threaded) collector events, the "user" + "sys" time should be approximately equal to the "real" (wall) time multiplied by the # of GC threads. For example, if there are 3 GC threads we would expect a parallel collection that takes 1 second of "real" time to take approximately 3 seconds of "user" + "sys" time. The parallelism is 3x. If the parallelism is 1x ("user" + "sys" = "real"), the parallel collection is not offering any efficiency over a serial (single-threaded) collection. When "user" + "sys" < "real", the parallelism is inverted. Inverted parallelism can be a sign of high i/o (e.g. disk or network access) or not enough CPU (e.g. GC threads competing with each other or other processes). Check for swapping and if the number of GC threads (-XX:ParallelGCThreads=<n>) is appropriate for the number of cpu/cores and any processes sharing cpu.