[concurrency-interest] Object finalization

Roman Elizarov elizarov at devexperts.com
Tue May 15 03:35:09 EDT 2012


I wonder what are the legitimate use-cases for finalization? The actual *usage* of finalization in Java runtime is deeply flawed, because finalizers that reclaim native resources don't have a chance to run before you run out of native resources. For example, the code that leaks FileInputStream objects without closing them seems to work correctly on small heaps, but crashes with different JVM options, running out of native fds.

So, are there any sound use-cases for finalizers at all?

On 15.05.2012, at 2:05, "Boehm, Hans" <hans.boehm at hp.com<mailto:hans.boehm at hp.com>> wrote:

In my view, the hard problem is finalization while a method is running.  Fixing that the obvious way has a probably small, but nonzero optimization cost.  (Essentially no dead variable elimination on reference variables.  Guesses among the optimization experts in the C++ committee were around a 1% slowdown to support a semi-esoteric feature.  I don’t know of any real measurements.)  We came up with some compromises in a C++ context in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html .

I think the other issues could be solved fairly easily.  In my view Modula 3 adequately solved the ordering issue by insisting on ordered finalization, which is essentially what you now get out of java.lang.ref, though in a less direct way.  As far as I know, Modula-3 users generally agreed with that assessment, but Java and C# designers did not, and came up with what I consider to be a much worse point in the design space, at least for finalization itself.  I also don’t see why, given a solution to the early finalization problem, it would be difficult to ensure that the last object access happens before finalization.  Standard garbage collectors probably have each thread stop operation synchronize with finalization anyway.

Hans

From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Monday, May 14, 2012 3:05 PM
To: Boehm, Hans
Cc: concurrency-interest at cs.oswego.edu<mailto:concurrency-interest at cs.oswego.edu>; Bob Lee; dholmes at ieee.org<mailto:dholmes at ieee.org>
Subject: Re: [concurrency-interest] Object finalization


Raymond Chen (MSFT) has an interesting series of posts on finalization, including this one which demonstrates your example Hans: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/13/10049634.aspx

CLR team even added GC.KeepAlive() to try and alleviate some causes of this race.  Then there's a whole slew of bugs that can happen due to memory write ordering/visibility since finalizer thread is subject to same issues as normal threads.  Then in CLR finalizer can run even if constructor fails (I believe JVM does not?), possibly causing broken state/invariants to be observed.  Finalizers are one of those well intentioned ideas that goes haywire ... :)

Sent from my phone
On May 14, 2012 4:58 PM, "Boehm, Hans" <hans.boehm at hp.com<mailto:hans.boehm at hp.com>> wrote:
But things are considerably worse than that.  References only solve the easy problem.  The most serious problem in my mind is that finalizers can run, and references can be enqueued, while e.g. a method of the object being finalized is still running.  The fact that the method is still running does not ensure that the object itself is still reachable; the method may only need fields that have already been cached in registers to complete.  This affects finalizers and java.lang.ref equally, and explains why probably the large majority of code using either one is broken.

I gave a JavaOne talk about this many years ago (slides at http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf).  It is possible, though really ugly and slow to work around the problem.  I don’t believe anyone does.  I was told just after I gave the talk that this explained a problem somebody had been trying to track down, so I suspect this actually happens occasionally in the wild, though probably not on x86-32.

Hans

From: concurrency-interest-bounces at cs.oswego.edu<mailto:concurrency-interest-bounces at cs.oswego.edu> [mailto:concurrency-interest-bounces at cs.oswego.edu<mailto:concurrency-interest-bounces at cs.oswego.edu>] On Behalf Of Bob Lee
Sent: Monday, May 14, 2012 11:01 AM
To: dholmes at ieee.org<mailto:dholmes at ieee.org>
Cc: concurrency-interest at cs.oswego.edu<mailto:concurrency-interest at cs.oswego.edu>
Subject: Re: [concurrency-interest] Object finalization

On Sun, May 13, 2012 at 11:22 PM, David Holmes <davidcholmes at aapt.net.au<mailto:davidcholmes at aapt.net.au>> wrote:
I should add the Vitaly's comments prompted me to remember that 'a' and 'b' might refer to objects that themselves have been finalized prior to the current finalizer running. This just reinforces how tricky finalization is.

Indeed, the finalizers can run in any order, independent of the structure of the object graph.

For those who are interested in learning more, I cover that and half a dozen other reasons not to use finalizers in this talk: http://www.parleys.com/#id=2657&st=5

Thanks,
Bob
Square is hiring!<https://squareup.com/jobs>


_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120515/d5ba2b79/attachment-0001.html>


More information about the Concurrency-interest mailing list