Re: [Gc] Trouble with disappearing links

Hi Christian, 
You should alway do access to such fields (including read) inside a callback routine called from GC_call_with_alloc_lock.
--
Fri, 08 Aug 2014, 09:30 +04:00 from Christian Schafmeister <[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

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc