JFR Event for Full GCs

[Andrew Azores]

Hmm. It's along the right lines (and I had overlooked it before) but I 
don't think this event meets the requirement. I modified my JMC testing 
rule to look for those events while running my reproducer applet with 
-XX:+UseG1GC -XX:+PrintGCDetails. My run saw one OldGarbageCollection 
event emitted but the GC log output does not show any Full GC events. I 
also tried reading through the JFR and GC sources again to trace the 
execution path where this event is emitted, and although I wasn't 100% 
confident, it didn't look to me like this event is 1:1 with Full 
collections - perhaps a Full collection implies this event emission but 
not vice-versa? From my limited understanding of the GC phases and 
generations this would seem to make sense.

On 2018-12-04 10:26 a.m., Erik Gahlin wrote:
> There is an OldCollection event which is typically triggered during a full collection, but is perhaps not sufficient for your use case?
> 
> Erik
> 
>> On 4 Dec 2018, at 15:04, Andrew Azores <aazores at redhat.com> wrote:
>>
>> Hi all,
>>
>> I'm looking into a JMC bug report [0] for adding a JFR rule to detect Full GC events. From what I could tell playing around with JMC and then by reading through the JFR and JDK GC sources, there does not seem to be an existing Full GC event, not any event that corresponds 1:1 with a full collection. There is the jdk.GarbageCollection event, but I don't see that any of its properties can be used to reliably indicate Full GC vs otherwise for all collectors (or at least both G1 and CMS as specified in the bug report). If this assumption is wrong please let me know and point me in the right direction.
>>
>> If a JFR event does need to be added or modified to enable tracking full collection occurrences, would the preferred approach be to modify the jdk.GarbageCollection event with a field to denote the collection type, or to emit an entirely new event flagging a full collection? My personal leaning would be toward a new event marked experimental, but I defer to the experts.
>>
>> Once I have guidance on the questions above I would be glad to prepare and submit a patch for your approval.
>>
>> Thanks,
>>
>> [0] https://bugs.openjdk.java.net/browse/JMC-5596
>>
>> -- 
>> Andrew Azores
>> Software Engineer, OpenJDK Team
>> Red Hat
> 


-- 
Andrew Azores
Software Engineer, OpenJDK Team
Red Hat