On Wed, 19 May 2021 09:00:27 GMT, Alan Bateman <al...@openjdk.org> wrote:
> I wonder if there needs to be one event per finalized object? I also concern with the performance overhead of one event per finalized object. The primary goal of this JFR event is to help identifying the use of finalizers in existing libraries/applications and prepare them to migrate away from using finalization. As well-known, the finalization mechanism is inherently problematic. > Perhaps a counter per class would be as useful, i.e. > jdk.FinalizationStatistics, and if it could be implemented in the VM, without > other implications, that would be great. Therefore, a counter per class would be useful as it identifies the usage of finalizers while providing the number of objects per class pending for finalization (see `ReferenceQueue::enqueue` and `ReferenceQueue::reallyPoll` where it keeps track of the pending for finalization counter). Another option is to go with a simple approach - just report the aggregated number of `Finalizer` objects per class which still meets the primary goal to identify what existing code uses finalizers and the counter gives the users an additional information how many finalizers are created. BTW the number of finalizer invocation is not more useful than the number of `Finalizer` instances unless we provide both counters so that the users can determine the number of objects pending for finalization. > Such an event could be enabled by default and provide much greater value than > an event that users would need to know about and configure themselves, which > 99,99% of all user will not do. I agree an event enabled by default is more useful provided that the performance overhead is insignificant. I was also thinking if this event should be implemented in the VM in order to avoid some performance overhead such as object allocation. Erin, what is the benefit of implementing in in the VM? ------------- PR: https://git.openjdk.java.net/jdk/pull/4101
