On Wed, 19 May 2021 06:20:59 GMT, Erik Gahlin <egah...@openjdk.org> wrote:
> This looks useful, but I am worried about the performance impact: > > * The added allocation for every object that is finalized. > * The event being enabled in the default configuration. > > The default configuration must be safe to use even in pathological cases, > i.e. an application with lots of objects being finalized. It's probably too > much overhead (or number of events) for the profile configuration as well. > > There is also the added startup cost of JFR. One event may not matter that > much, but they all add up. We need to put in place a mechanism that doesn't > rely on bytecode instrumentation at runtime. There is an enhancement for > that, but it requires some engineering first. I'm a bit worried by this too. Does it need to be enabled by default? Can we put a static final instance of FinalizerEvent in that class that can be used to test if the event is enabled so that it doesn't create a FinalizerEvent when disabled? Is it worth exploring doing have an event in the VM, in register_finalizer, instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/4101
