Colin Gordon | 14 Oct 20:27 2014

[Gc] Compiling bdwgc via emscripten

Hi,

I’ve been trying to compile bdwgc with the Emscripten support recently upstreamed from Unity.  But I cannot figure out how to produce a working build.  From glancing at the relevant changes on github, and following Emscripten’s build integration instructions, I’ve tried essentially using:

emconfigure ./configure —prefix=.../gcout/ --without-threads --disable-threads __EMSCRIPTEN__=1 EMSCRIPTEN=1

I’ve tried with and without explicitly setting CC, CXX, etc.  This produces a shared library file containing LLVM bit code, which when disassembled appears to contain the relevant GC symbols and the expected target triple “asmjs-unknown-emscripten.”  But linking against this result fails with emscripten searching for intermediate JavaScript files that do not exist.  “make check” (and “emmake make check”) fail all tests.  Are there any docs on the emscripten support?  I haven’t been able to locate any.  Can anyone suggest what I might be missing or doing incorrectly?

If relevant, I’m using the Emscripten portable SDK on Mac OS X.

Thanks,
Colin
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Stefan Kral | 11 Oct 16:58 2014
Picon

[Gc] Alignment/padding of small objects on 64-bit platform (x86-64)

Hello.

My app operates on a lot of 3-word objects and I wonder if it would be reasonable to adapt the granule size accordingly.

The application requires 64-bit pointers and has no double-word alignment requirements, so I would be keen on reducing the memory requirement.

I'm grateful for any advise and/or tips!

Best Regards,
Stefan.
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
张睿 | 8 Oct 18:00 2014
Picon

[Gc] Cannot make cord/tests/{cordtest,de}

After ./configure and make && make install, I have only a gc.h under $(prefix)/include/, and the following files under $(prefix)/include/gc/ directory:

cord.h  gc_allocator.h  gc_config_macros.h  gc_gcj.h     gc_mark.h               gc_tiny_fl.h  gc_version.h  leak_detector.h
gc.h    gc_backptr.h    gc_disclaim.h       gc_inline.h  gc_pthread_redirects.h  gc_typed.h    javaxfc.h     weakpointer.h

There are two reasons that I cannot make cord/tests/{cordtest,de}.

First, cordtest.c and de.c include cord.h, which is not present in $(prefix)/include/ but $(prefix)/include/gc instead. The latter is not in gcc's search directories.

Second, cord_pos.h is not installed, but cord.h includes this file.

A quick fix for me is to copy cord_pos.h to $(prefix)/gc/ manually and replace #include "cord.h" with #include "gc/cord.h".

It seems to me that the building script needs to be updated for cord-related stuff. I have looked into the documentation (doc/README.cords) but I didn't find anything useful.
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Laurent Deniau | 8 Oct 14:54 2014
Picon
Picon

[Gc] Tests crashing

Dear All,

I have included the gc-7.2d in our physics code about 1.5 years ago and it was running like a charm until
recently after an update of the Intel icc compiler to 14.0.4 (gcc 4.9.1 installed) on our MacOSX 10.8.5
server (and my laptop). Now GC_init is crashing with a segfault during a call to __intel_memset according
to gdb, but this occurs only in 32 bit mode compiled with Intel icc 14.0.4 on MacOSX. Gcc 32/64 bit and Intel
64 bit work fine on MacOSX as well as all GCC/Intel 32/64 bit combination on Linux and Windows 7. I tried with
7.2d, 7.2f, 7.4.2 from the tarball, and last release from git without success. It's difficult to say if the
problem is in the Intel libs (no source…) or in the Gc code. I suspect a memory alignment problem because I
successfully triggered some "bus error" from time to time instead of a segfault and Intel __intel_memset
uses intensively the SSE instructions set. It is very possible that the bug comes from Intel libs (i.e.
32/64 bit vs selection of SSE instructions set) but I wanted to know if someone else encountered the
problem? I attach the output of the libgc compilation using icc and gcc in 32 and 64 bit for crosscheck.

BTW, on 7.4.2 and the git version, I had to correct an invalid selection of snprintf in the Cord test, where
snprintf was selected but the buffer size (2nd) argument was discarded (i.e. sprintf-like args),
shifting the literal string format to the buf size position and so on. Don't ask me how this can happen
considering the defines above…

the warning points line 247 in
https://github.com/ivmai/bdwgc/blob/master/cord/tests/cordtest.c
forcing snprintf with correct args works well.

Thanks,
Laurent.

--
Laurent Deniau			http://cern.ch/mad
Accelerators Beam Physics	mad@...
CERN, CH-1211 Geneva 23		Tel : +41 (0) 22 767 4647

Attachment (libgc-gnu.out.gz): application/x-gzip, 12 KiB
Attachment (libgc-intel.out.gz): application/x-gzip, 12 KiB
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Andrew Hills | 4 Oct 19:44 2014
Picon

[Gc] Building with musl

Hi all,

Has anyone successfully built Boem-GC with the musl libc? The last
information I found was a few threads[0][1] on this list from 1.75 years
ago.

Thanks,
Andrew

[0] https://lists.opendylan.org/pipermail/bdwgc/2013-January/005525.html
[1] https://lists.opendylan.org/pipermail/bdwgc/2013-January/005531.html

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Ivan Maidanski | 11 Sep 19:11 2014
Picon

Re: [Gc] [bdwgc] Assertions when glibc uses lock elision (#51)

Hi Jan,

I have merged fix-tsx-bug commit to master (as well as release-7_4 branch).
Note that this fix (workaround) enabled only for linux/x64 at this moment. To enable it for x86, use -DFIX_GLIBC_TSX_BUG . Please test it whether it is OK for x86. If it solves the issue I'll change the code to define the macro implicitly for linux/x86.

OTOH, this workaround has performance drawback (in locking) for linux/intel platforms which do not have TSX. Could we exclude such targets by checking TSX presence at runtime?

Regards,
Ivan

-----

Monday, 08 Sept 2014, 12:22 +04:00 from Jan Alexander Steffens <notifications <at> github.com>:

guile: ../nptl/pthread_mutex_lock.c:80: __pthread_mutex_cond_lock: Assertion mutex->__data.__owner == 0' failed.
gc's testsuite also randomly asserts. Strangely, it seems to happen soon after start or not at all.
The fix_tsx_bug branch in its current state (commit  757af8a ) works on x86_64 but not i686, which continues to assert.
Meanwhile, the glibc maintainers assert that this is not their bug.

Reply to this email directly or  view it on GitHub .

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Jonathan Chambers | 5 Sep 15:14 2014
Picon

[Gc] Pushing Registers for Collector Thread

Hello,

Posting to the mailing list an issue one of our customers raised with us and on github. We (Unity) use bdwgc within the Mono VM. We are running an older version, but the issue highlighted still seems to persist in master. 


I believe this may apply to more architectures/platforms, but at the moment I'll reference Win64. In GC_push_stack_for, all threads push their stack sections. However, when pushing register values the current thread is skipped:


This leads to a case where memory may be collected while still in use. Suppose an function allocates memory from the GC and it gets stored in a volatile register (RCX for example on Win64). No pointer on the stack or managed heap reference this allocation. Now a collection is triggered. 

If any subsequent functions in the call chain between the allocating function and GC_push_stack_for does use RCX, the original value should be pushed onto the stack and restored later as it's a volatile register. This stack reference will be found and marked since we push the current thread stack.

However, if any subsequent functions in the call chain between the allocating function and GC_push_stack_for does *not* use RCX the reference will be not be marked and will be collected.

On Windows/OSX this seems to always be the case. In pthread_stop_world.c I see calls to GC_save_regs_in_stack for SPARC and Itanium. Is there a reason this is not done/needed for all platforms?

If this is indeed a bug, we can provide patches for all the platforms we support.

Thanks,
Jonathan
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
David Given | 19 Aug 00:34 2014

[Gc] Storing pointers to GC objects in non-GC memory

I'm trying to make libgc work with an Ada program.

Persuading Ada to allocate objects with libgc is pretty easy. Persuading
it to allocate *all* objects with libgc is rather hard --- in a modern
environment the standard libraries and runtimes are all precompiled
shared objects, so replacing their references to malloc() isn't really
an option.

According to the libgc docs, libgc doesn't scan blocks allocated with
system malloc(). This means that if I allocate a block from libgc, then
store the pointer in a block allocated with system malloc() --- such as
an Ada standard container data structure --- then libgc won't see the
pointer, will think the object is unreferenced, and free it, right?

Is there anything I can do here or am I fundamentally doomed? The exact
wording of the libgc docs are that libgc doesn't 'usually' scan blocks
from system malloc() --- what does 'usually' mean here?

--

-- 
┌─── dg@cowlark.com ─────
http://www.cowlark.com ─────
│ "Blue is beautiful... blue is best...
│ I'm blue! I'm beautiful! I'm best!"
│ --- _Dougal and the Blue Cat_

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Juan Wajnerman | 10 Aug 01:36 2014
Picon

[Gc] Segfault during parallel collection

I'm having trouble combining parallel gc with coroutines made with libpcl (http://xmailserver.org/libpcl.html).
To allow the gc to deal with the coroutine stacks I register a callback with GC_set_push_other_roots. Whenever a coroutine starts or stops the GC_stackbottom is replaced. Only the portions of the coroutine stacks that are actually used are lately pushed when the "push_other_roots" callback is invoked.

This seems to work fairly well most of the time, but sometimes seems like something is not properly initialized and it crashes with the following backtrace:

0   libgc.1.dylib                 0x0000000104392d9b GC_do_parallel_mark + 28
1   libgc.1.dylib                 0x0000000104392249 GC_mark_some + 422
2   libgc.1.dylib                 0x000000010438b58d GC_stopped_mark + 119
3   libgc.1.dylib                 0x000000010438b4b1 GC_try_to_collect_inner + 260
4   libgc.1.dylib                 0x000000010438c292 GC_collect_or_expand + 188
5   libgc.1.dylib                 0x000000010438c48a GC_allocobj + 167
6   libgc.1.dylib                 0x0000000104390ba9 GC_generic_malloc_inner + 350
7   libgc.1.dylib                 0x0000000104391bb7 GC_generic_malloc_many + 977
8   libgc.1.dylib                 0x0000000104398aa3 GC_malloc_atomic + 135
...


The reason I suspect the problem is with the initialization is because during a stress test the crash occurs very early in the first grabage collection or it doesn't happen at all even after tens of GBs are allocated and freed.
The stress test only runs on a single thread, entering and leaving many coroutines that allocate memory. This problem doesn't occur if I run the test using GC_NPROCS=1

It's complicated to give an example because it's not even C/C++ code. I'm working on a new programming language. However you can get an idea of what I'm trying to do reading this code: https://github.com/manastech/crystal/blob/master/src/fiber/pcl.cr#L102

Any ideas? Should I place some lock around the "push_other_roots" initialization?

Thanks!
- Juan Wajnerman

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Christian Schafmeister | 8 Aug 07:30 2014
Picon
Picon

Re: [Gc] Trouble with disappearing links

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 <bruce-zQEARAI6hqHYtjvyW6yDsg@public.gmane.org> 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 <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> 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 <chris.schaf-H+0wwilmMs3R7s880joybQ@public.gmane.org> 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 <at> 0x11464c1d8) > 
> (low-level-describe ht)
(low-level-describe ht)
WeakKeyHashTable   size: 16
   keys memory range:  0x1142e0c00  - 0x1142e0d00 
   0  key.px <at> 0x1142e0c00  unbound
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 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 <at> 0x1142e0c00  (1 . 2) <at> 0x1120c5700   -->   9999
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 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 <at> 0x1142e0c00  (1 . 2) <at> 0x1120c5700   -->   9999
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 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 <at> 0x1142e0c00  nil
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 0x1142e0cf0  unbound



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
bdwgc mailing list
bdwgc-ZwoEplunGu1I4Lznb4ZCK0B+6BGkLq7r@public.gmane.org
https://lists.opendylan.org/mailman/listinfo/bdwgc


_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Christian Schafmeister | 6 Aug 20:03 2014
Picon
Picon

[Gc] Trouble with disappearing links


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 <at> 0x11464c1d8) > 
> (low-level-describe ht)
(low-level-describe ht)
WeakKeyHashTable   size: 16
   keys memory range:  0x1142e0c00  - 0x1142e0d00 
   0  key.px <at> 0x1142e0c00  unbound
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 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 <at> 0x1142e0c00  (1 . 2) <at> 0x1120c5700   -->   9999
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 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 <at> 0x1142e0c00  (1 . 2) <at> 0x1120c5700   -->   9999
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 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 <at> 0x1142e0c00  nil
   1  key.px <at> 0x1142e0c10  unbound
   2  key.px <at> 0x1142e0c20  unbound
   3  key.px <at> 0x1142e0c30  unbound
   4  key.px <at> 0x1142e0c40  unbound
   5  key.px <at> 0x1142e0c50  unbound
   6  key.px <at> 0x1142e0c60  unbound
   7  key.px <at> 0x1142e0c70  unbound
   8  key.px <at> 0x1142e0c80  unbound
   9  key.px <at> 0x1142e0c90  unbound
   10  key.px <at> 0x1142e0ca0  unbound
   11  key.px <at> 0x1142e0cb0  unbound
   12  key.px <at> 0x1142e0cc0  unbound
   13  key.px <at> 0x1142e0cd0  unbound
   14  key.px <at> 0x1142e0ce0  unbound
   15  key.px <at> 0x1142e0cf0  unbound

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc

Gmane