SV: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS

[Marcus Hirt]

Hi Andrew,

Looks good, but please fix the associated tests first, then
I'll take a closer look.

<--8<-->
[ERROR] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 9.674 s <<< FAILURE! - in org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr
[ERROR] verifyOneResult(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr)  Time elapsed: 2.398 s  <<< FAILURE!
java.lang.AssertionError:


Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report.
        at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159)
        at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyOneResult(TestRulesWithJfr.java:126)

[ERROR] verifyAllResults(org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr)  Time elapsed: 7.234 s  <<< FAILURE!
java.lang.AssertionError:


Report for file "wls-medrec-jdk9.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "wldf.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "stringdedup_enabled_jdk9.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "parallel-on-singlecpu.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "parallel-gc_cpu.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "flight_recording_hidden.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "crash_jdk9.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "allocation_10s_fixed.jfr", rule result for "FullGc" could not be found in the other report.

Report for file "allocation_10s_before.jfr", rule result for "FullGc" could not be found in the other report.
        at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyRuleResults(TestRulesWithJfr.java:159)
        at org.openjdk.jmc.flightrecorder.test.rules.jdk.TestRulesWithJfr.verifyAllResults(TestRulesWithJfr.java:132)
<--8<-->

Kind regards,
Marcus


-----Ursprungligt meddelande-----
Från: jmc-dev <jmc-dev-bounces at openjdk.java.net> För Andrew Azores
Skickat: den 10 december 2018 22:36
Till: jmc-dev at openjdk.java.net
Ämne: RFR: JMC-5596: Rule to detect if there has been a Full GC with G1 or CMS

Hi,

Here is a patch addressing JMC-5596 [0]. A new JFR rule is added which detects Full GC occurrences when either the G1 or CMS collectors are in use. The implementation for detecting these events is based on my own reading through and testing of JDK (11) sources, as well as discussions on the hotspot-jfr-dev list [1].

For G1 the collections are detected by filtering for jdk.GarbageCollection events where the gcName field is set to "G1Full", since the G1 sources do in fact have separate tracers to identify New, Old, and Full collections by G1. Furthermore, manual testing shows perfect agreement between the G1Full event count and the "Pause Full" 
log message (-XX:+PrintGCDetails) count.

For CMS the picture is a little more hazy, but the jdk.OldGarbageCollection event is used, since this appears to be emitted in the expected situations and was mentioned in the hotspot-jfr-dev discussion. Unfortunately, CMS does not have separate tracers like G1, so the jdk.GarbageCollection events seemingly cannot be filtered by the type of collection that they represent. In my testing there are sometimes discrepancies between the number of OldGarbageCollection events emitted and the number of "Pause Full" messages, but I have never seen a situation where there was 0 of one and >0 of the other (ie. a false positive or false negative result). I suspect there is a pathway that leads to >1 OldGarbageCollection event being emitted for only one log message.

Additionally, I have refactored the CollectorType enum, which is used by this new FullGcRule as well as the existing GcStallRule. I've updated the enum members so that it is inline with the GcName enum within the JDK itself, and cleaned up the implemenation of getOldCollectorType slightly.

[0] https://bugs.openjdk.java.net/browse/JMC-5596

[1]
http://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2018-December/000271.html

Thanks,
--
Andrew Azores
Software Engineer, OpenJDK Team
Red Hat