RFR: 8003216: Add JFR event indicating explicit System.gc() cal

Per Liden per.liden at oracle.com
Wed Feb 26 14:02:01 UTC 2020


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.

> 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.


> Thanks
> Erik
>> 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:
>>> Hi,
>>> 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.
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8003216
>>> Webrev:
>>> http://cr.openjdk.java.net/~egahlin/8003216/
>> 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?
>> cheers,
>> Per
>>> Testing:
>>> tier1+tier2+jdk/jdk/jfr
>>> Thanks
>>> Erik

More information about the hotspot-gc-dev mailing list