Re: [Gc] Trouble with disappearing links
Christian Schafmeister <[email protected]> Fri, 08 Aug 2014 01:30:28 -0400
| Newsgroups | gmane.comp.programming.garbage-collection.boehmgc |
|---|---|
| Message-ID | <[email protected]> |
Thank you, your suggestions gave me what I needed to get it working reliably. I’m not sure how asynchronously the Boehm collector updates disappearing links. Do I need to temporarily suspend the Boehm collector by suspending interrupts or signals while I’m updating my weak-key-hash-table? Best, .Chris. On Aug 6, 2014, at 5:08 PM, Bruce Hoult <[email protected]> wrote: > >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 > > No, it means what it says. GC_register_disappearing_link() is used for fields of normal scannable objects. If your finalizer tries to dereference a pointer field that just got zeroed then your program is going to crash. So if the finalizer uses a particular pointer, don't ask for it to disappear. > > The ECL code you quoted uses GC_general_register_disappearing_link() not GC_register_disappearing_link(). They do very different things. Possibly they should have names that are more different. > > > > On Thu, Aug 7, 2014 at 7:20 AM, Christian Schafmeister <[email protected]> wrote: > > 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 >> >> > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > bdwgc mailing list > [email protected] > https://lists.opendylan.org/mailman/listinfo/bdwgc > _______________________________________________ bdwgc mailing list [email protected] https://lists.opendylan.org/mailman/listinfo/bdwgc