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

[Thomas Schatzl]

On Tue, 22 Nov 2022 12:26:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I think the new event for ref-processing time should be roughly corresponding to its neighbor `<Event name="GCReferenceStatistics"` in `metadata.xml`, regardless of ref-processing being STW or not.

GCReferenceStatistics isn't dependent on whether the work has been performed in stw or concurrently; it shows number of the processed references in the last "pass".

> 
> > When/if we add concurrent reference processing time tracking (which isn't trivial to do)
> 
> @sangheon 's latest revision does that for Shenandoah and Z.

Okay, but addition of this is exactly what makes the event misleading (or hard to explain to users) as I tried to explain: the Shenandoah and Z timings are different in the circumstances they are taken:
* for ZGC and Shenandoah it means wall time for concurrent reference processing. This can be arbitrarily lengthened due to mutator impact.
* for Serial/Parallel it means wall time for stw reference processing. Which is probably fairly close to cpu time given it is done with the mutator suspended.
* for G1 which does both, concurrent weak/reference processing work (preclean) and stw reference processing, this event now only tracks the latter. Adding them together for this event obviously does not make sense. Maybe G1 is the odd one out? Then again, it is hard to add preclean time at the time when this event is sent, but imo that makes a stronger case for separate concurrent/stw reference processing events (and maybe not sending this stw event for shenandoah and Z)

I.e. the values between collectors are not comparable although they use the same event/value, and even missing out some parts now.

This explains my reluctance to mix different kind of work (concurrent vs. stw) in a single event/value. This can be really confusing (apart from losing G1's concurrent reference processing work here). That is the reason I liked the original limit of this PR's scope to just the stw part, even if that value was always zero for some collectors due to the way they work, better.

(All of these timings do not cover time spent in discovery, which is arguably also some kind of "reference processing", but probably not something this event wants to track)

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

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