RFR: 8003216: Add JFR event indicating explicit System.gc() cal
erik.gahlin at oracle.com
Wed Feb 26 15:17:29 UTC 2020
> On 26 Feb 2020, at 15:02, Per Liden <per.liden at oracle.com> wrote:
> On 2/26/20 2:50 PM, Erik Gahlin wrote:
>> Hi Per,
>> My thinking was that users expect the timestamp of the event to happen before the GarbageCollection event, so I made the event untimed.
> I would have expected the event start time to be before the collection starts, and the end time when it's done.
We have sometimes sorted events by their end time, or when they are committed (written to the buffer).This works better than start time in some cases.
>> I could make the event timed, but what happens if a concurrent gc is used and it is already in progress. Would a new gc cycle start, or will it complete the existing cycle before returning?
> Unless -XX:+ExplicitGCInvokesConcurrent is used (off by default), they do the same, which is wait until the "System.gc" collection has completed. For ZGC, should a GC cycle be in progress when a call to System.gc() is made, it will first wait for the in progress cycle to finish, and then execute the "System.gc" cycle before returning.
If users expect the System GC event to measure the time the Java thread is blocked, making the event timed makes sense.
If users expect the duration to be the length of the triggered GC, or even the pause time, it would mislead users to make it timed.
>>> On 26 Feb 2020, at 13:56, Per Liden <per.liden at oracle.com> wrote:
>>> 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?
More information about the hotspot-gc-dev