Quantcast

java.lang.ref.Finalizer locks

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

java.lang.ref.Finalizer locks

Milan Mimica
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?


Milan Mimica, Senior Software Engineer / Division Lead
Office: Mletacka 12/III, 52100 Pula, Croatia  |  Fax: +38552210979  |  Mobile: +385993061692
Email: [hidden email]  |  Skype: mmimicaib
www.infobip.com   /   GSMA Associate Member   /   Mobey Forum Member
This message is private and confidential. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Infobip d.o.o. If you have received this message in error, please notify us immediately via email to [hidden email] or telephone +442032864231.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.lang.ref.Finalizer locks

Peter Levart
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.lang.ref.Finalizer locks

Milan Mimica
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 <[hidden email]>
Sent: Monday, March 20, 2017 14:37
To: Milan Mimica; [hidden email]
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: java.lang.ref.Finalizer locks

Mandy Chung
In reply to this post by Peter Levart

> On Mar 20, 2017, at 6:37 AM, Peter Levart <[hidden email]> wrote:
>
> 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…

+1  Moving away from using finalizers is the right thing to do.

Mandy

Loading...