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

[Thomas Schatzl]

On Tue, 22 Nov 2022 07:21:39 GMT, Sangheon Kim <sangheki at openjdk.org> wrote:

>> Hi all,
>> 
>> Can I have reviews for this change that adds a new JFR event for total Reference Processing time?
>> 
>> The goal is to generate a new JFR event if there is already measured time. This CR doesn't add new time measurement.
>> 
>> Testing: hs-tier1 ~ 3
>> 
>> Thanks,
>> Sangheon
>
> Sangheon Kim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to report_gc_reference_processing_time(). Change test @requires to !=Epsilon.

I'm fine with either solution (i.e. to not send the event for not-supported collectors), but really, it depends on what this new event is supposed to capture.

I.e. the question is what the "total reference processing time" is supposed to mean: is it reference processing time in stw pauses? Or generally "total processing time" (including cpu time spent concurrently)?

To me it's the former, so a value of 0.0 is technically correct for the concurrent collectors (actually I'm not sure whether Shenandoah does fully concurrent reference processing). This would suggest to make it available for all collectors, as there is a difference between not having a value for some collectors as it may not only mean "the time is zero" (does not do stw reference processing) but also something like "the collector does not do this at all".

When/if we add concurrent reference processing time tracking (which isn't trivial to do), then it may be useful to add another event (or just a value to the existing one) to be able to discriminate between concurrent vs. time spent in stw.

-------------

PR: https://git.openjdk.org/jdk/pull/11230