RFR: 8003216: Add JFR event indicating explicit System.gc() cal
stefan.johansson at oracle.com
Thu Feb 27 09:13:50 UTC 2020
On 2020-02-26 18:28, Erik Gahlin wrote:
> Hi Stefan,
> GC-id would be nice, but perhaps not possible in all scenarios, i.e.
> -XX:+ExplicitGCInvokesConcurrent and Epsilon GC?
For ExplicitGCInvokesConcurrent it would not be a big problem, that
would start a concurrent cycle and we could use the id for that GC. I
also realized that we can get the GC-id without any problem. For other
events sent before the GC-id is properly setup, we use GCId::peek()
which returns the id that will be used for the next collection.
For Epsilon, I'm not sure an event should be sent at all since they are
blocked, see: EpsilonHeap::collect(...)
> On 2020-02-26 14:21, Stefan Johansson wrote:
>> Hi Erik,
>>> 26 feb. 2020 kl. 13:56 skrev Per Liden <per.liden at oracle.com>:
>>> Hi Erik,
>>> On 2020-02-26 13:50, Erik Gahlin wrote:
>>>> Could I have a review of a JFR event that is emitted when
>>>> System.gc() is called.
>>>> Purpose is to collect the stack trace. It is not sufficient with the
>>>> cause field that the GarbageCollection event has today.
>>> 489 EventSystemGC event;
>>> 490 event.commit();
>>> 491 Universe::heap()->collect(GCCause::_java_lang_system_gc);
>>> Don't you want the commit() call after the call to collect(), to get
>>> the timing right?
>> I was thinking the same thing, could also be nice to have the GC-id
>> associated with the event to make it easy to match it to GC-logs and
>> other GC-events. Not sure how to easily get the GC-id though, since
>> it’s not set at the time we commit the event.
>> I guess if the event has the correct span with timestamps it will be
>> easy to figure out which other events are associated with it, even
>> without the GC-id.
More information about the hotspot-gc-dev