RFR: 8292266: Add JFR event for total Reference processing time [v3]

[Erik Gahlin]

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