RFR: 8292266: Add JFR event for total Reference processing time [v3]
Erik Gahlin
egahlin at openjdk.org
Mon Nov 21 17:03:23 UTC 2022
On Fri, 18 Nov 2022 23:28:41 GMT, Sangheon Kim <sangheki at openjdk.org> wrote:
>> src/hotspot/share/gc/shared/gcTrace.cpp line 76:
>>
>>> 74: send_reference_stats_event(REF_PHANTOM, rps.phantom_count());
>>> 75:
>>> 76: send_reference_process_time_event(rps.total_process_time());
>>
>> I think this is called by all collectors, but Z and Shenandoah would have zero for "total process time" here. I am not sure if this causes confusion on reading the jfr reports.
>
> You are right and this is current scope of this CR.
> If both collectors measure spent time, we can add it later. Hopefully under separate CR.
>
> Or if the confusion only comes from zero value of the measured time, we can avoid sending zero value event. i.e. skip sending ref-proc-time event for both collectors.
> My first commit is something like this but stopped as someone may complain lack of the event anyway.
> > Or if the confusion only comes from zero value of the measured time
>
> Yes, that's the confusion I was referring to.
>
> > My first commit is something like this but stopped as someone may complain lack of the event anyway.
>
> I see; I actually like the approach in your first commit better -- separate methods for reporting ref counts and processing time. If an event is not supported for a particular collector, it should not be emitted for that collector, IMO.
>
> I still feel the behavior, reporting zero for ref-processing time for Shenandoah and Z, can be surprising, so I'd prefer this is avoided. However, if others think this is fine, I would not block this.
I agree about the zeros.
I also prefer that events are implemented for all collectors. It confusing for users or tools that consume the data to not get it for all GCs. I understand it is more work, but I rather delay the event a release than having something that is only partly done for JDK 20.
-------------
PR: https://git.openjdk.org/jdk/pull/11230
More information about the hotspot-jfr-dev
mailing list