[Gc] GC_register_disappearing_link

Hans Boehm Hans.Boehm at hp.com
Fri Nov 5 15:07:54 PST 2004


Reachability for GC_register_disappearing_link does not consider
finalizer (clean-up) reachable objects to be reachable.  The link
is cleared if the object is unreachable from ordinary roots.  The
documentation should be clearer.

I'm actually less concinced that this functionality is essential than
I once was.  It can help performance in some cases.  But other idioms,
relying only on finalization, will usually also work.

For some details see my paper:

"Destructors, Finalizers, and Synchronization", POPL 2003.  (URLs at
http://www.hpl.hp.com/personal/Hans_Boehm/pubs.html)

Hans

On Thu, 4 Nov 2004, Hans Van den Eynden wrote:

> Hello
>
> I am trying to understand the working of the GC. Something is not clear
> to my.
> In gc_cpp.h there is:
> "An object is considered "accessible" by the collector if it can be
> reached by a path of pointers from static variables, automatic
> variables of active functions, or from some object with clean-up
> enabled; pointers from an object to itself are ignored."
>
> and
>
> "Thus, if objects A and B both have clean-up functions, and A points at
> B, B is considered accessible.  After A's clean-up is invoked and its
> storage released, B will then become inaccessible and will have its
> clean-up invoked.  If A points at B and B points to A, forming a
> cycle, then that's considered a storage leak, and neither will be
> collectable.  See the interface gc.h for low-level facilities for
> handling such cycles of objects with clean-up."
>
> This text in gc.h is rather confusing:
>
> /* The following routine may be used to break cycles between    */
> /* finalizable objects, thus causing cyclic finalizable        */
> /* objects to be finalized in the correct order.  Standard    */
> /* use involves calling GC_register_disappearing_link(&p),    */
> /* where p is a pointer that is not followed by finalization    */
> /* code, and should not be considered in determining         */
> /* finalization order.                        */
> GC_API int GC_register_disappearing_link GC_PROTO((GC_PTR * /* link */));
>     /* Link should point to a field of a heap allocated     */
>     /* object obj.  *link will be cleared when obj is    */
>     /* found to be inaccessible.  This happens BEFORE any    */
>     /* finalization code is invoked, and BEFORE any        */
>     /* decisions about finalization order are made.        */
>     /* This is useful in telling the finalizer that     */
>     /* some pointers are not essential for proper        */
>     /* finalization.  This may avoid finalization cycles.    */
>     /* Note that obj may be resurrected by another        */
>     /* finalizer, and thus the clearing of *link may    */
>     /* be visible to non-finalization code.          */
>     /* There's an argument that an arbitrary action should  */
>     /* be allowed here, instead of just clearing a pointer. */
>     /* But this causes problems if that action alters, or     */
>     /* examines connectivity.                */
>     /* Returns 1 if link was already registered, 0        */
>     /* otherwise.                        */
>     /* Only exists for backward compatibility.  See below:    */
>
> gc_cpp says that an object is accessible if been pointed to from an
> collectable object with a clean-up function. So how can
> GC_register_disappearing_link
> solve this?? GC_register_disappearing_link will only clear *link if it
> is inaccesible.
>
> thx
>
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>


More information about the Gc mailing list