[concurrency-interest] Object finalization

David M. Lloyd david.lloyd at redhat.com
Tue May 15 09:15:48 EDT 2012


I've given up on finalization for native resources for just this reason; 
instead I use refcounting.  It's not great because there's a CAS on 
entry+exit but I find that I can also use the same trick to replace 
locking in many cases so I'm hoping that it'll even out in the 
benchmarks.  I almost have myself convinced that it will scale better 
than the finalizer option.  We shall see.

On 05/15/2012 02:35 AM, Roman Elizarov wrote:
> 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
>> <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
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


-- 
- DML


More information about the Concurrency-interest mailing list