[concurrency-interest] Object finalization

Vitaly Davidovich vitalyd at gmail.com
Mon May 14 23:04:09 EDT 2012


It sounds like delay_finalization() in your link serves the same purpose as
GC.KeepAlive(this) in the CLR.  As you point out in that paper,
artificially extending the lifetime of the this reference would be costly
on architectures with a small register set.  In addition, under heavy load
where this race is more likely to occur you also risk an OOM if the object
graph of "this" is very large.  I'm not sure how often this race is
actually a problem in practice (people are usually encouraged to not impl a
finalized or if they do, keep it dead simple), so perhaps a developer hint
(ala delay_finalization/GC.KeepAlive) is a decent compromise.

As for mem ordering/visibility, are you suggesting that there should always
be a membar before the finalizer picks up the reference to process? Might
get kind of expensive on many core (especially NUMA) machines and if, e.g.,
multiple finalizer threads are ever used.  If multiple finalizer threads
are used, I don't see why you'd want them to synchronize with GC as
presumably they could run concurrently with either GC threads or even
mutators.  If we're saying that ease of use/correctness is more important
than performance for finalization processing, then it makes sense.  It's a
tricky problem as ultimately you'll find competing use cases (perf vs ease
of use).

Cheers

Sent from my phone
On May 14, 2012 8:01 PM, "Boehm, Hans" <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; Bob Lee; 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> 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] *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 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120514/c91d38c3/attachment-0001.html>


More information about the Concurrency-interest mailing list