Milan.Mimica at infobip.com
Mon Mar 20 14:21:19 UTC 2017
I created them a task: https://jira.spring.io/browse/SPR-15363
You don't suppose it would be worth trying to play with RegisterFinalizersAtInit? Maybe
it could help for some reason if the registration was moved a bit earlier.
Milan Mimica, Senior Software Engineer / Division Lead
From: Peter Levart <peter.levart at gmail.com>
Sent: Monday, March 20, 2017 14:37
To: Milan Mimica; core-libs-dev at openjdk.java.net
Subject: Re: java.lang.ref.Finalizer locks
On 03/20/2017 02:13 PM, Milan Mimica wrote:
> Hope you can help me with an advice.
> I'm using a library, namely spring-jdbc, which implements java.lang.Object.finalize() in one static inner class which does get instantiated *a lot*. It creates significant contention on synchronized block in java.lang.ref.Finalizer from Object's constructor. Are there any plans to improve this (except from removing it)? I can see it's not trivial, but maybe it could be reimplemented lock-free?
There were past attempts in this area (using concurrent doubly linked
list similar to the one in java.util.concurrent.ConcurrentLinkedDeque)
that did improve the contention a bit. Another drag is also the fact
that the Finalizer.register() method that must be invoked from VM as
part of object construction prevents certain optimizations in VM that
non-finalizable object constructors enjoy.
So the most productive way would be to ask Spring developers to remove
finalization and instead employ their own PhantomReference based cleanup
and/or adopt new JDK 9 Cleaner API when time comes...
More information about the core-libs-dev