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
Hi,
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.
cheers,
Per
>
> 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-jfr-dev
mailing list