RFR: 8266936: Add a finalization JFR event [v2]

[Chris Hegarty]

On Tue, 18 May 2021 22:41:06 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test flag should be volatile

My 0.02$ ;-)  I really like the idea of a jdk.FinalizationStatistics event. The devil is (as always) in the details.

Multiple concerns have been raised above, which benefit from being separated out:

1) Raising an event per invocation of each individual finalizer may be costly when JFR is enabled (since there could be an extremely large number of these), as well as a little unwieldy for a human observer. Aggregating invocations of finalizers and reporting periodically seems like a nice solution to this.

2) A jdk.FinalizationStatistics event that provides an aggregate count of *all* finalizer invocations seems most straightforward, but less useful. A jdk.FinalizationStatistics event that provides per-class invocation metrics seems more useful, but at the expense of a more complex event structure. Maybe model jdk.FinalizationStatistics as a tuple of Class and long (count) - periodically committing multiple jdk.FinalizationStatistics events, one event per class? ( or was the thought to somehow aggregate all these per-class metrics into a single jdk.FinalizationStatistics event? )

3) If we keep the currently proposed semantic - capturing actual invocation/queueing counts (rather than registrations), then I see no reason why the implementation of a jdk.FinalizationStatistics needs to be in the JVM. The metrics can be captured in Java code and reported in a similar way to the container metrics (being proposed in [PR 3126][PR3126]). Surely, this would be more straightforward to implement and maintain, no?

4) The startup cost of JFR. I dunno enough about this, but what I do know is that a handler needs to be spun per Java-event, so maybe this has some bearing on the decision of no.3 above?

[PR3126]: https://github.com/openjdk/jdk/pull/3126

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

PR: https://git.openjdk.java.net/jdk/pull/4101