Basile Starynkevitch | 25 May 10:20 2016

[Gc] using a lot of finalizers?


In my MELT monitor (see 
for details) I am having a lot finalizers. You might consider (GC-wise) 
that it is sort-of some Lisp (but multi-threaded, with a small thread 
pool of about half a dozen threads) interpreter.

Basically, I have (conceptually) a lot of immutable GC-ed values 
(allocated with GC_MALLOC) and some mutable GC-ed "items" (also 
allocated with GC_MALLOC). Those items are registering a finalizer with 

In the event I would have a large (e.g. a dozen of gigabytes) GC heap, 
is it acceptable to have many (e.g. half a million) of items with 
finalizers and much more (e.g. several millions) values.

So my question becomes: can I have many items, each having registered a 
finalizer, or is it not acceptable performance-wise?

Or should I put a lot of design effort to avoid finalizers?

My blind guess is that since "gc/gc_cpp.h" is using 
GC_REGISTER_FINALIZER_IGNORE_SELF it should be acceptable to have a lot 
of finalizers.



email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
(Continue reading)

Chris Metcalf | 2 May 17:41 2016

[Gc] [PATCH] Implement the basic atomic primitives for the tilegx/tilepro cpus.

* src/ (nobase_private_HEADERS): Add tile.h.
* src/atomic_ops.h: Include tile.h file.
* src/atomic_ops/sysdeps/gcc/tile.h: New file.
For libatomic_ops:

This patch is an updated version of the CentOS 6 patch that we have
been carrying as part of our own CentOS-like distribution since 2012.

 src/                   |    1 +
 src/atomic_ops.h                  |    3 ++
 src/atomic_ops/sysdeps/gcc/tile.h |   52 +++++++++++++++++++++++++++++++++++++
 3 files changed, 56 insertions(+), 0 deletions(-)
 create mode 100644 src/atomic_ops/sysdeps/gcc/tile.h

diff --git a/src/ b/src/
index d463427..8971370 100644
--- a/src/
+++ b/src/
 <at>  <at>  -84,6 +84,7  <at>  <at>  nobase_private_HEADERS = atomic_ops/ao_version.h \
           atomic_ops/sysdeps/gcc/s390.h \
           atomic_ops/sysdeps/gcc/sh.h \
           atomic_ops/sysdeps/gcc/sparc.h \
+          atomic_ops/sysdeps/gcc/tile.h \
           atomic_ops/sysdeps/gcc/x86.h \
           atomic_ops/sysdeps/hpc/hppa.h \
diff --git a/src/atomic_ops.h b/src/atomic_ops.h
index ec02ba4..59f04ef 100644
--- a/src/atomic_ops.h
(Continue reading)

Chris Metcalf | 2 May 17:42 2016

[Gc] [PATCH] gcconfig.h: Add machine description for TILE-Gx and TILEPro

For bdwgc:

This patch is an updated version of the CentOS 6 patch that we have
been carrying as part of our own CentOS-like distribution since 2012.

 include/private/gcconfig.h |   48 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h
index 760f896..beac61c 100644
--- a/include/private/gcconfig.h
+++ b/include/private/gcconfig.h
 <at>  <at>  -574,6 +574,14  <at>  <at> 
 #    define HEXAGON
 #    define mach_type_known
 # endif
+# if defined(__tile__) && defined(LINUX)
+#   ifdef __tilegx__
+#      define TILEGX
+#   else
+#      define TILEPRO
+#   endif
+#   define mach_type_known
+# endif

 # if defined(SYMBIAN)
 #   define mach_type_known
 <at>  <at>  -635,6 +643,8  <at>  <at> 
                     /*             CRIS       ==> Axis Etrax            */
(Continue reading)

Andy Li | 12 Apr 21:33 2016

[Gc] website is down


The website,, is currently down.
Is it under maintenance or something? 

Best regards,
bdwgc mailing list
Eric Lindblad | 27 Mar 20:11 2016

[Gc] gc / Interix

To Whom m it May Concern,

I would enquire if you might assess what are the appropriate gc code modifications for porting to the
Interix sub-system. I am on SFU 3.5 Interix (32 bit) where I appropriated getopt.h, inttypes.h and
stdint.h from SFU 6.0 Interix, but I realise that there also have been released amd64 and ia64 Interix
versions. Though presently my interests are gc as a dependency for running the pager/text browser w3m
(where a static gc is suitable) if the Microsoft Corp. developers would oblige my request and resuscitate
the Interix project - beginning with 8.1 Microsoft no longer enabled new Windows versions for Interix -
the gc port (including shared libraries and threading) might be useful for other applications to be run
under SFU/SUA Interix.

I use WeirdX ( as a X Server with a tab window manager (twm).

Ohara for gc6.4.tar.gz on the Japanese webpage at
in his "gc_interix.diff" (./configure --disable-threads --enable-cplusplus) has the following code:

# $OpenXM: OpenXM_contrib2/asir2000/gc_interix.diff,v 1.1 2004/02/27 18:32:21 ohara Exp $
--- include/private/gc_priv.h.orig	Tue Jun 24 14:11:42 2003
+++ include/private/gc_priv.h	Thu Feb 26 08:10:31 2004
 <at>  <at>  -19,6 +19,10  <at>  <at> 
 # ifndef GC_PRIVATE_H
 # define GC_PRIVATE_H

+#if defined(__INTERIX)
+#define __CYGWIN__
 #if defined(mips) && defined(SYSTYPE_BSD) && defined(sony_news)
     /* sony RISC NEWS, NEWSOS 4 */
 #   define BSD_TIME

Where if one modifies include/private/gcconfig.h, it being obvious to add this '__INTERIX' clause 

# if defined(__INTERIX)
#   define I386
#   define INTERIX
#   define mach_type_known
# endif

which attends to the error message "include/private/gcconfig.h:456: error: parse error before '--'
token", on gc6.4.tar.gz, and, on newer versions, e.g.,  gc-7.2d.tar.gz, to the returned error message
"The collector has not been ported to this machine/OS combination.", for gc-6.8.tar.gz Martin Koeppe
( has also
this code modification for include/private/gcconfig.h,

 #	undef STACK_GRAN
 #       define STACK_GRAN 0x10000
 #       define HEURISTIC1
+#   ifdef INTERIX
+#       define OS_TYPE "INTERIX"
+        extern int _data_start__[];
+        extern int _bss_end__[];
+#       define DATASTART ((ptr_t) _data_start__)
+#       define DATAEND   ((ptr_t) _bss_end__)
+#       define STACKBOTTOM ({ptr_t rv;           \
+             __asm __volatile ("movl %%fs:4,%%eax" \
+            :"=a"(rv)); rv;})
+#       define USE_MMAP
+#       define USE_MMAP_ANON
 #   endif
 #   ifdef OS2
 #	define OS_TYPE "OS2" 

and he adds this in

+     *-*-interix*)
+        ;;

Eric Lindblad

P.S. For some code compilation under Interix
one also adds the flag "-D_ALL_SOURCE".
Ivan Maidanski | 24 Mar 21:19 2016

[Gc] libatomic_ops CAS ordering constraints correspondence to C11 atomic ones

Hello Hans,

AO Readme.txt is a bit weak in respect to CAS ordering constraints. Let's fix it by mapping to C11 atomic memory ordering (based on common sense and inspection of libatomic_ops exsiting CAS assembly implementations).

Is the following correct?
|| AO CAS suffix || C11 CAS success || C11 CAS failure ||
| -            | __ATOMIC_RELAXED | __ATOMIC_RELAXED |
| full        | __ATOMIC_SEQ_CST  | __ATOMIC_ACQUIRE |


Best regards,
bdwgc mailing list
John Mastro | 15 Mar 19:39 2016

[Gc] BDWGC and tagged pointers


I suspect this question is quite basic, but I haven't been able to
figure it out on my own.

I'm implementing a small programming language and would like to use
BDWGC for garbage collection. I'm using tagged pointers, where the 3
least-significant bits can carry a type tag. The tagged value may be
either an immediate (e.g. an integer) or a pointer. In other words, I
have something like this:

    typedef intptr_t object;

    #define TAG_BITS 3
    #define VAL_MASK -(1 << TAG_BITS)

    enum obj_tag { TAG_INT = 1, TAG_LIST };

    typedef struct {
        object head, tail;
    } obj_list;

    #define make_integer(i)    (((i) << TAG_BITS) + TAG_INT)
    #define extract_integer(o) ((o) >> TAG_BITS)

    object make_list(object head, object tail)
        obj_list *list = /* allocate it */;
        list->head = head;
        list->tail = tail;
        return ((intptr_t)list) + TAG_LIST;

    #define extract_list(o) ((void *)((o) & VAL_MASK))

... which I think is pretty standard/boring. However, I believe I need
to teach BDWGC about this tagging, so it knows these `object` values may
(or may not) represent pointers, and I'm not sure how to do that.

Are there any documents, examples, or other help on how to accomplish


John Mastro
Marek Vasut | 11 Mar 23:56 2016

[Gc] [PATCH] Add nios2 support via gcc helper

Add initial nios2 architecture support.

Signed-off-by: Marek Vasut <marex@...>
V2: Update the licensing text to match the rest
 src/                    |  1 +
 src/atomic_ops.h                   |  3 +++
 src/atomic_ops/sysdeps/gcc/nios2.h | 17 +++++++++++++++++
 3 files changed, 21 insertions(+)
 create mode 100644 src/atomic_ops/sysdeps/gcc/nios2.h

diff --git a/src/ b/src/
index fc09b27..d463427 100644
--- a/src/
+++ b/src/
 <at>  <at>  -79,6 +79,7  <at>  <at>  nobase_private_HEADERS = atomic_ops/ao_version.h \
           atomic_ops/sysdeps/gcc/ia64.h \
           atomic_ops/sysdeps/gcc/m68k.h \
           atomic_ops/sysdeps/gcc/mips.h \
+          atomic_ops/sysdeps/gcc/nios2.h \
           atomic_ops/sysdeps/gcc/powerpc.h \
           atomic_ops/sysdeps/gcc/s390.h \
           atomic_ops/sysdeps/gcc/sh.h \
diff --git a/src/atomic_ops.h b/src/atomic_ops.h
index 33fe00e..ec02ba4 100644
--- a/src/atomic_ops.h
+++ b/src/atomic_ops.h
 <at>  <at>  -262,6 +262,9  <at>  <at> 
 # if defined(__m68k__)
 #   include "atomic_ops/sysdeps/gcc/m68k.h"
 # endif /* __m68k__ */
+# if defined(__nios2__)
+#   include "atomic_ops/sysdeps/gcc/nios2.h"
+# endif /* __nios2__ */
 # if defined(__powerpc__) || defined(__ppc__) || defined(__PPC__) \
      || defined(__powerpc64__) || defined(__ppc64__)
 #   include "atomic_ops/sysdeps/gcc/powerpc.h"
diff --git a/src/atomic_ops/sysdeps/gcc/nios2.h b/src/atomic_ops/sysdeps/gcc/nios2.h
new file mode 100644
index 0000000..7fb7400
--- /dev/null
+++ b/src/atomic_ops/sysdeps/gcc/nios2.h
 <at>  <at>  -0,0 +1,17  <at>  <at> 
+ * Copyright (C) 2016 Marek Vasut <marex@...>
+ *
+ *
+ * Permission is hereby granted to use or copy this program
+ * for any purpose,  provided the above notices are retained on all copies.
+ * Permission to modify the code and to distribute modified code is granted,
+ * provided the above notices are retained, and a notice that the code was
+ * modified is included with the above copyright notice.
+ */
+#include "../test_and_set_t_is_ao_t.h"
+#include "generic.h"
+#define AO_T_IS_INT

sigint | 10 Mar 10:22 2016

[Gc] Wrong __data_start/_end pair Abort


when I compile and run the following code, I get a message and an Abort. 
When I run it in gdb

$ cat test.c

#include "gc.h"

int main () {
     int *p;
     p = GC_MALLOC(sizeof(int));
     return 0;

$ gcc test.c -lgc

$ ./a.out
Wrong __data_start/_end pair

$ uname -a
Linux localhost 3.10.49 #1 SMP PREEMPT Mon Nov 16 12:46:20 CST 2015 
armv71 Android

Any suggestion on how to proceed. gdb did not show anything interesting.

Ivan Maidanski | 17 Feb 22:13 2016

[Gc] Fwd: Large offset in negative GC_DS_PER_OBJECT descriptors can lead to arbitrary data being misinterpreted as type descriptors (#92)

Copied to ML

-------- Forwarded message --------
From: Niklas Therning <notifications <at>>
CC: ivmai/bdwgc <bdwgc <at>>
Date: Wed, 17 Feb 2016, 16:45 +03:00
Subj: [bdwgc] Large offset in negative GC_DS_PER_OBJECT descriptors can lead to arbitrary data being misinterpreted as type descriptors (#92)

Added a check in GC_mark_from() for GC_DS_PER_OBJECT objects with negative descriptors to prevent mistaking the free list pointers in free objects for being type descriptor pointers. If the specified descriptor offset was larger than the object size this could lead to arbitrary data from allocated objects
being misinterpreted as descriptors and the process crashing.
The patch tries to determine if the object pointed to by type_descr is large enough to hold a type descriptor at the configured offset. If it's too small current_p is ignored.
To illustrate the problem I have pasted some info from LLDB below when a crash occurred in GC_mark_from(). current_p in GC_mark_from() is 0x31eca68 which is a free object (i.e. not allocated) but it's probably marked due to being referenced by the stack. mark_stack_top has the following value:
(lldb) p *mark_stack_top
(mse) $1 = {
  mse_start = 0x031eca68 "P\xffffffca\x1e\x03"
  mse_descr = (w = 4294967219, sw = -77, vp = 0xffffffb3, ao = 4294967219)
The mse_descr value (0xffffffb3) is a GC_DS_PER_OBJECT with our MARK_DESCR_OFFSET of 64.
The hblkhdr of the block containing this object:
(lldb) p *(struct hblkhdr*)0x432c660
(struct hblkhdr) $2 = {
  hb_next = 0x00000000
  hb_prev = 0x00000000
  hb_block = 0x031ec000
  hb_obj_kind = '\x04'
  hb_flags = '\0'
  hb_last_reclaimed = 1
  hb_sz = 24
  hb_descr = 4294967219
  hb_map = 0x00fef0f8
  hb_n_marks = 112
  _mark_byte_union = (_hb_marks = char [513] <at> 0x7f9fc43b1c50, dummy = 16777217)
As can be seen size (hb_sz) of objects in this block is 24.
Dump of 10 objects of size 24 bytes around current_p (0x31eca68):
(lldb) memory read -G 60wx -l 6 current_p-24*5
0x031ec9f0: 0x031ec9d8 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x031eca08: 0x031ec9f0 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x031eca20: 0x031eca08 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x031eca38: 0x031eca20 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x031eca50: 0x031eca38 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x031eca68: 0x031eca50 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x031eca80: 0x00fdb4c0 0x00000000 0x00000005 0x30303336 0x00000030 0x00000000
0x031eca98: 0x00fdb4c0 0x00000000 0x00000005 0x30303236 0x00000030 0x00000000
0x031ecab0: 0x00fdb4c0 0x00000000 0x00000005 0x30303136 0x00000030 0x00000000
0x031ecac8: 0x00fdb4c0 0x00000000 0x00000005 0x30303036 0x00000030 0x00000000
The free list link pointers can clearly be seen in this dump. The object at 0x031eca68 points at 0x031eca50, which points at 0x031eca20, etc.
To get the actual GC descriptor the GC will dereference the first word:
(lldb) p *(void**)current_p
(void *) $3 = 0x031eca50
Add our MARK_DESCR_OFFSET of 64 (this is a 32-bit process):
(lldb) p (*(char**)current_p)+64
(char *) $4 = 0x031eca90 "0"
And read the value at that memory position:
(lldb) p *(word*)((*(char**)current_p)+64)
(word) $5 = 48
You can view, comment on, or merge this pull request online at:
Commit Summary
*  Added a check in GC_mark_from() for GC_DS_PER_OBJECT objects with negative
File Changes
*  M mark.c (20)
Patch Links:

Reply to this email directly or  view it on GitHub .

bdwgc mailing list
Marek Vasut | 27 Jan 21:43 2016

[Gc] libatomic-ops nios2


I am trying to add support for nios2 CPU into libatomic-ops and gc .
The Linux kernel exports kuser helper for cmpxchg [1], so I believe
this might be the way to go? Or shall I somehow use the gcc atomic
builtin ops [2] ? Note that nios2 does not have dedicated atomic
instructions which could be used in userland, that's why the kuser

Thank you for any input!


Best regards,
Marek Vasut