[Gc] Re: Defeating finalization

Ludovic Courtès ludovic.courtes at laas.fr
Fri Apr 21 01:49:16 PDT 2006


"Boehm, Hans" <hans.boehm at hp.com> writes:

> It appears to me that what you are proposing should work fine.  To
> faithfully implement guardians, I think you need
> GC_register_finalizer_no_order.  (I personally don't believe that's a
> wise design choice, even though it appears to deal withy cyclic
> finalization.  Which explains why the documentation tends to
> discourage it.)

So you mean that it's safe to create new references to the object being
finalized from within the finalizer?  It is guaranteed that the GC will
not reclaim an object's storage if its finalizer creates new references
to it?

My expectation was that the GC might behave as follow:

  if (object_is_unreachable (obj))
      invoke_finalizer (obj);
      GC_free (obj);

In this case, creating new references to OBJ from within the finalizer
would have been a bad idea.

> Note that neither [0] nor our current GC implementation pays
> sufficient attention to what I would now consider to be by far the
> most serious issue with finalizers/guardians/weak-pointers/...:
> Objects may be unreachable while one of their methods (or a function
> taking the object as a parameter) is still running and accessing some
> external state associated with the object.  See for example the slides
> at
> https://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf
> .

Maybe I don't understand the issue well enough, but it seems that the
problem your slides are referring to mostly stems from the fact that in
Java, "[e]ven if the client is single-threaded, finalizers run in their
own thread," which brings a concurrency issue.  Is this correct?


More information about the Gc mailing list