Hello Peter 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.lev...@gmail.com> Sent: Monday, March 20, 2017 14:37 To: Milan Mimica; core-libs-dev@openjdk.java.net Subject: Re: java.lang.ref.Finalizer locks Hi Milan, On 03/20/2017 02:13 PM, Milan Mimica wrote: > Hello > > 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... Regards, Peter
