[concurrency-interest] Object finalization

David Holmes davidcholmes at aapt.net.au
Tue May 15 04:08:47 EDT 2012

As long as the Object constructor completes the object will be registered
for finalization.

  -----Original Message-----
  From: Dr Heinz M. Kabutz [mailto:heinz at javaspecialists.eu]
  Sent: Tuesday, 15 May 2012 6:06 PM
  To: Vitaly Davidovich
  Cc: Boehm, Hans; concurrency-interest at cs.oswego.edu; dholmes at ieee.org
  Subject: Re: [concurrency-interest] Object finalization

  The finalizer definitely runs even if the constructor fails (in other
words, throws an exception).  It's the trick we use to solve the Chicken and
Egg puzzle in Wouter Coekaert's blog:



Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
Tel: +30 69 75 595 262
Skype: kabutz

  On 5/15/12 1:05 AM, Vitaly Davidovich wrote:
    Raymond Chen (MSFT) has an interesting series of posts on finalization,
including this one which demonstrates your example Hans:

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


      From: 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
      Cc: 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> 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

      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:



      Square is hiring!

      Concurrency-interest mailing list
      Concurrency-interest at cs.oswego.edu

Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120515/4aa2df1a/attachment.html>

More information about the Concurrency-interest mailing list