Re: [Gc] Trouble with disappearing links
Christian Schafmeister <[email protected]> Wed, 06 Aug 2014 15:20:13 -0400
| Newsgroups | gmane.comp.programming.garbage-collection.boehmgc |
|---|---|
| Message-ID | <[email protected]> |
Following up on my own question I looked into ECL which uses the Boehm garbage collector and supports weak pointers.
It uses this code to allocate a weak pointer with GC_MALLOC_ATOMIC which contains objects that are not scanned for pointers.
I don’t see any mention of this in the documentation unless the statement “where p is a pointer that is not followed by finalization code” is supposed to indicate that you put the pointer in memory that is not scanned for pointers.:
/* 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. */
——— ECL code below ————
static cl_object
ecl_alloc_weak_pointer(cl_object o)
{
const cl_env_ptr the_env = ecl_process_env();
struct ecl_weak_pointer *obj;
ecl_disable_interrupts_env(the_env);
obj = GC_MALLOC_ATOMIC(sizeof(struct ecl_weak_pointer));
ecl_enable_interrupts_env(the_env);
obj->t = t_weak_pointer;
obj->value = o;
if (!ECL_FIXNUMP(o) && !ECL_CHARACTERP(o) && !Null(o)) {
GC_general_register_disappearing_link((void**)&(obj->value), (void*)o);
si_set_finalizer((cl_object)obj, ECL_T);
}
return (cl_object)obj;
}
On Aug 6, 2014, at 2:03 PM, Christian Schafmeister <[email protected]> wrote:
>
> I’m using disappearing links for the first time (I may not know what I’m doing) and they seem to be keeping the object that they are pointing to alive.
> I don’t know why the disappearing link is not disappearing and appears to keep the object it points to alive.
> Should I not be allocating the memory that contains the disappearing link within the Boehm managed memory?
>
> Pseudo code:
> 1) I’m implementing a weak key hash table
> 2) I allocate two parallel arrays (key array/value array) using GC_MALLOC.
> 3) I write a key and value into each corresponding array.
> 4) I call GC_register_disappearing_link(&key[0]). This should make the key entry at index 0 a disappearing link.
> 5) Then I destroy all references to the key other than what are in the array.
> 6) The key object stays alive until I reset the key[0] entry - then it gets finalized.
>
>
> Here is a transcript of the Common Lisp session:
>
> > (setq ht (make-weak-key-hash-table))
> (setq ht (make-weak-key-hash-table))
>
> #<CORE:WEAK-KEY-HASH-TABLE @0x11464c1d8) >
> > (low-level-describe ht)
> (low-level-describe ht)
> WeakKeyHashTable size: 16
> keys memory range: 0x1142e0c00 - 0x1142e0d00
> 0 key.px@0x1142e0c00 unbound
> 1 key.px@0x1142e0c10 unbound
> 2 key.px@0x1142e0c20 unbound
> 3 key.px@0x1142e0c30 unbound
> 4 key.px@0x1142e0c40 unbound
> 5 key.px@0x1142e0c50 unbound
> 6 key.px@0x1142e0c60 unbound
> 7 key.px@0x1142e0c70 unbound
> 8 key.px@0x1142e0c80 unbound
> 9 key.px@0x1142e0c90 unbound
> 10 key.px@0x1142e0ca0 unbound
> 11 key.px@0x1142e0cb0 unbound
> 12 key.px@0x1142e0cc0 unbound
> 13 key.px@0x1142e0cd0 unbound
> 14 key.px@0x1142e0ce0 unbound
> 15 key.px@0x1142e0cf0 unbound
>
> > (setq key (cons 1 2))
> (setq key (cons 1 2))
>
> (1 . 2)
> > (weak-hash-table-put ht 0 key 9999)
> (weak-hash-table-put ht 0 key 9999)
> ../../src/gctools/gcalloc.h:969 Registered disappearing link 0x1142e0c00 obj 0x1120c5700 return val = 0
>
> > (low-level-describe ht)
> (low-level-describe ht)
> WeakKeyHashTable size: 16
> keys memory range: 0x1142e0c00 - 0x1142e0d00
> 0 key.px@0x1142e0c00 (1 . 2)@0x1120c5700 --> 9999
> 1 key.px@0x1142e0c10 unbound
> 2 key.px@0x1142e0c20 unbound
> 3 key.px@0x1142e0c30 unbound
> 4 key.px@0x1142e0c40 unbound
> 5 key.px@0x1142e0c50 unbound
> 6 key.px@0x1142e0c60 unbound
> 7 key.px@0x1142e0c70 unbound
> 8 key.px@0x1142e0c80 unbound
> 9 key.px@0x1142e0c90 unbound
> 10 key.px@0x1142e0ca0 unbound
> 11 key.px@0x1142e0cb0 unbound
> 12 key.px@0x1142e0cc0 unbound
> 13 key.px@0x1142e0cd0 unbound
> 14 key.px@0x1142e0ce0 unbound
> 15 key.px@0x1142e0cf0 unbound
>
> > (setq key nil) ;;; Here I wipe out the only non-disappearing reference to the key
> (setq key nil) ;;; Here I wipe out the only non-disappearing reference to the key
>
> NIL
> > (gctools:garbage-collect) ;; I force garbage collections - the key object is not collected although I think it should be
> (gctools:garbage-collect)
>
> > (gctools:garbage-collect)
> (gctools:garbage-collect)
>
> > (gctools:garbage-collect)
> (gctools:garbage-collect)
>
> > (gctools:garbage-collect)
> (gctools:garbage-collect)
>
> > ;; No finalization messages have been printed
> ;; No finalization message
>
> > (low-level-describe ht) ;; Here we see the key object is still alive
> (low-level-describe ht)
> WeakKeyHashTable size: 16
> keys memory range: 0x1142e0c00 - 0x1142e0d00
> 0 key.px@0x1142e0c00 (1 . 2)@0x1120c5700 --> 9999
> 1 key.px@0x1142e0c10 unbound
> 2 key.px@0x1142e0c20 unbound
> 3 key.px@0x1142e0c30 unbound
> 4 key.px@0x1142e0c40 unbound
> 5 key.px@0x1142e0c50 unbound
> 6 key.px@0x1142e0c60 unbound
> 7 key.px@0x1142e0c70 unbound
> 8 key.px@0x1142e0c80 unbound
> 9 key.px@0x1142e0c90 unbound
> 10 key.px@0x1142e0ca0 unbound
> 11 key.px@0x1142e0cb0 unbound
> 12 key.px@0x1142e0cc0 unbound
> 13 key.px@0x1142e0cd0 unbound
> 14 key.px@0x1142e0ce0 unbound
> 15 key.px@0x1142e0cf0 unbound
>
> > ;; Key is still there
> ;; Key is still there
>
>
> > (weak-hash-table-put ht 0 nil 9999)
> (weak-hash-table-put ht 0 nil 9999)
> ../../src/gctools/gcalloc.h:969 Registered disappearing link 0x1142e0c00 obj 0x9 return val = 1
>
> > (gctools:garbage-collect) ;; Now the object will be collected and a finalization function called
> (gctools:garbage-collect)
> ../../src/gctools/gcalloc.h:894 Boehm finalized weak linked address 0x1120c5700 at 0x1142e0c00
>
> > (low-level-describe ht)
> (low-level-describe ht)
> WeakKeyHashTable size: 16
> keys memory range: 0x1142e0c00 - 0x1142e0d00
> 0 key.px@0x1142e0c00 nil
> 1 key.px@0x1142e0c10 unbound
> 2 key.px@0x1142e0c20 unbound
> 3 key.px@0x1142e0c30 unbound
> 4 key.px@0x1142e0c40 unbound
> 5 key.px@0x1142e0c50 unbound
> 6 key.px@0x1142e0c60 unbound
> 7 key.px@0x1142e0c70 unbound
> 8 key.px@0x1142e0c80 unbound
> 9 key.px@0x1142e0c90 unbound
> 10 key.px@0x1142e0ca0 unbound
> 11 key.px@0x1142e0cb0 unbound
> 12 key.px@0x1142e0cc0 unbound
> 13 key.px@0x1142e0cd0 unbound
> 14 key.px@0x1142e0ce0 unbound
> 15 key.px@0x1142e0cf0 unbound
>
> >
_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc