[concurrency-interest] Object finalization

David Holmes davidcholmes at aapt.net.au
Mon May 14 02:22:28 EDT 2012

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.

  -----Original Message-----
  From: Chris Vest [mailto:mr.chrisvest at gmail.com]
  Sent: Monday, 14 May 2012 4:15 PM
  To: Vitaly Davidovich
  Cc: dholmes at ieee.org; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Object finalization

  Thanks guys,

  I did indeed only include the constructor to show that neither `a` nor `b` would be null after construction.

  On 14 May 2012 01:10, Vitaly Davidovich <vitalyd at gmail.com> wrote:

    Ok, thanks for the correction -- I must've remembered it being the same as CLR.  In the CLR, it doesn't guarantee that references to 'a' and 'b' would be null, but that they *may* be null due to undefined order of reclaimation -- no explicit clearing of them needs to happen.



    On Sun, May 13, 2012 at 6:28 PM, David Holmes <davidcholmes at aapt.net.au> wrote:

      The objects referred to by 'a' and 'b' will remain finalizer-reachable until after the finalizer runs and so can not be reclaimed. If they were to be reclaimed it would require that all references to them in finalizable objects be found and cleared, which is not practical.

      With regard to the OP, as long as the constructor completes normally, it is guaranteed that neither 'a' nor 'b' will be null when the finalizer runs. 

        -----Original Message-----
        From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Vitaly Davidovich
        Sent: Monday, 14 May 2012 8:20 AM
        To: Bob Lee
        Cc: concurrency-interest at cs.oswego.edu
        Subject: Re: [concurrency-interest] Object finalization

        perhaps I'm misremembering but there's no guarantee on the order in which objects are reclaimed.  When SomeService finalizer runs and assuming a and b were kept alive only by this instance of SomeService, I don't think there's any guarantee that a and b have not been reclaimed at this point already.  That's how the CLR finalization works, so perhaps I'm conflating the two.

        Sent from my phone

        On May 13, 2012 5:54 PM, "Bob Lee" <crazybob at crazybob.org> wrote:

          On Sun, May 13, 2012 at 2:41 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

            I am unclear whether the original question is specifically about reachability of a and b from the constructor or whether the constructor was shown to us to indicate that a and b are never null after construction (assuming asserts are enabled).  If it's the former, your answer is correct (that's what I meant by saying not sure if your reply was answering the question).  If it's the latter, then I'm pretty sure my response is correct

          Again, according the JLS, you're incorrect. "a" and "b" will be non-null when SomeService.finalize() executes. Why would you think otherwise?

          Square is hiring!

    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/20120514/0ad29e03/attachment.html>

More information about the Concurrency-interest mailing list