JFR Event for Full GCs
Erik Gahlin
erik.gahlin at oracle.com
Tue Dec 4 18:01:05 UTC 2018
Should Runtime::gc(), DiagnosticCommandMBean::gcRun() and
MemoryMXBean::gc() also be included?
> On a related note, it would be nice to have events (with stack traces)
> for System.gc() calls:
> https://bugs.openjdk.java.net/browse/JDK-8003216
>
> /M
>
> - Excuse me if terse; sent from my phone.
>
> On 4 Dec 2018, at 16:26, Erik Gahlin <erik.gahlin at oracle.com
> <mailto:erik.gahlin at oracle.com>> 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
>>> <mailto: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
>>
More information about the hotspot-jfr-dev
mailing list