[Gc] GC_register_disappearing_link

Hans Van den Eynden hans.vandeneynden at student.kuleuven.ac.be
Sun Nov 14 01:26:39 PST 2004


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

How does collector know that when obj is inaccessible it must clear *link??
Does it always search the complete list? Is this function used in 
GC_general_register_disappearing_link(GC_PTR * link, GC_PTR obj) and 
should we not use GC_register_disappearing_link GC_PROTO((GC_PTR * /* 
link */)); ?

> 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://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc>
/>/ http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
/>





More information about the Gc mailing list