On Tue, 18 May 2021 22:41:06 GMT, Brent Christian <bchri...@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
