gmane.comp.programming.garbage-collection.boehmgc

Determine if current thread is attached

Alex Rønne Petersen — 2012-05-26T19:24:23

Hi,

Is there a way to determine whether the currently-executing thread is
attached to the GC?

I *could* call GC_register_my_thread and switch on the return value,
but this feels like a very dirty hack, since in the non-DUPLICATE
case, I need to detach the thread again...

Thanks in advance!

Regards,
Alex

There should be a library major bump of gc library due to now having several GC_xyz "hidden" functions

Paulo César Pereira de Andrade — 2012-05-26T18:22:11

  I understand that those functions are in gc_priv.h, but at least
ecl became broken in Fedora 17 and rawhide due to the new GC_INNER
that causes those functions to have
__attribute__((__visibility__("hidden")))

  I made a Fedora RFE for gc, adding a new patch, at
https://bugzilla.redhat.com/show_bug.cgi?id=825473
where the patch changes GC_INNER to __attribute__((deprecated))

  A side effect is that during the gc package build, there will
be several warnings about it calling deprecated functions.

  This of course will not magically make things work, but with a
library major bump at some point it would make it easier to have
two libraries cohexisting, and in the meantime, people would be
warned about the functions being "deprecated".

Thanks,
Paulo

Can sigaltstack be used in a GC registered thread?

Jean-Claude Beaudoin — 2012-05-21T01:34:12

Hi,

After reading the GC sources for a while trying to figure out the
minimal stack requirements for GC function calls I came across
the following consideration:

"sigaltstack" cannot be used in a thread registered with the GC
since the stack analysis the GC would perform during a collect
would be invalid if the collection were to happen during the
dynamic-extent of a signal handler using that "alternate stack".

Am I wrong on this or is this in fact the case?

BTW, a bit of googling shows that mono seems to be facing
the same issue.

I am a bit surprised that I did not get a single reply to my previous
message to this list about call stack overflow handling.
I insert here below a copy of the message in case it was simply
misrouted.

The structure of this GC makes it live at the outer edge of an
application call tree making the probability that a call stack
overflow may happen during the execution of a GC function
quite significant.  Currently if such a thing happens the GC
simply seems to crash the whole a

Symbols with hidden attribute in gc-7.2

Paulo César Pereira de Andrade — 2012-05-20T18:36:58

  Hi,

  I am working on several dependency packages with goal to package
sagemath in fedora. But rawhide did update to gc-7.2 that now tags
several functions as GC_INNER.

  The problem is that that breaks one of the sagemath packages, that
is http://ecls.sourceforge.net/

  I had an open bug report for ecl for another issue, but in the meantime
I did upgrade to Fedora rawhide... The bug report was due to a dead
lock in ecl and gc usage of signals to stop threads, see:

https://sourceforge.net/tracker/?func=detail&aid=3526174&group_id=30035&atid=398053

  I understand that ecls calls private gc functions, but would like to
suggest to ecl upstream some alternative to correct problem.

Thanks,
Paulo

Handling of a stack overflow during GC?

Jean-Claude Beaudoin — 2012-05-19T11:13:50

Hi,

I am currently working on improving the code handling call stack overflow
in my Common Lisp environment MKCL (http://common-lisp.net/project/mkcl/).
MKCL uses a somewhat older (7.2a4) version of the Boehm conservative GC.

I would like to know what would happen if a stack overflow were to occur during
a GC call/collection? The GC code seems to replace the SIGSEGV handler at
some point, will this new SIGSEGV handler still use the alternate signal
stack that MKCL has setup?

Also, as a side question, do you have an estimate of the stack depth
requirements of the GC?  It seems to be at least twice the usual
value of PTHREAD_STACK_MIN (which happens to be 16k on Linux).

Thanks for your help,

Jean-Claude Beaudoin

Disappearing link unregistration

Alex Rønne Petersen — 2012-05-12T15:48:04

Hi,

If I allocate an object A and an object B and register a disappearing
link from A to B (i.e. A is the weak reference), do I have to
explicitly unregister the disappearing link from A to B when A becomes
garbage? If so, is registering a finalizer that does this the best
approach? If not, is doing it anyway going to improve performance or
be beneficial in some way?

Regards,
Alex

Fwd: New BDWGC release tarballs

Ivan Maidanski — 2012-05-12T09:49:54

Hi Hans,

Please check you mailbox for my previous letter containing temp links to the tarballs.

Regards,
Ivan Maidanski

-------- Forwarded message --------
From: Ivan Maidanski <ivmai-JGs/UdohzUI< at >public.gmane.org>
To: "Boehm,  Hans" <hans.boehm-VXdhtT5mjnY< at >public.gmane.org>
Date: Sat, 12 May 2012 13:46:19 +0400
Subject: New BDWGC release tarballs

Hi Hans,

Here are the tarballs for GC & libatomic_ops (both 7.2 final and 7.3alpha2):
***/gc-7.2.tar.gz
***gc-7.3alpha2.tar.gz
***/libatomic_ops-7.2.tar.gz
***/libatomic_ops-7.3alpha2.tar.gz

gc-7.2 contains libatomic_ops (v7.2) - same as in the previous v7 versions.

Please check them and when you make them available on HPL site, I'll push the commits to Github repo (and bump version for 7.3alpha).

Regards
----------------

Can global new / delete used for collected objects?

Hank William — 2012-05-11T18:39:23

Hi, excellent work on the library - but I do have a quick question:

Ideally we'd like to make all new / delete operations create collectable
objects (to avoid memory leaks from accidental use of "new" instead of
"new(GC)").

However the library itself does not do this by default and instead
overrides new / delete simply to mark the memory for scanning
(not collecting).

Is there a reason to avoid setting the default global new / delete
to create collectable objects?

Thanks!

The GC_INIT() macro and binding libgc in D

Alex Rønne Petersen — 2012-05-11T17:42:23

Hello folks,

In making a binding for libgc in the D programming language, I've come
across one particular macro in gc.h that worries me a lot: GC_INIT().
As you may or may not know, D doesn't have macros, nor does it support
directly including a C header file, so one has to write type and
function declarations matching those of the C header file. This
strategy actually works fine in most cases, except when the C code
makes heavy use of macros.

In libgc's case, GC_INIT() is very important for portable programs.
The idea is apparently that it is defined to do some extra work needed
for certain platforms that make initialization more painful than one
would prefer. On other platforms, it just calls GC_init(). I'm
honestly not sure why this additional logic isn't simply inside
GC_init() instead of using macros. Having the logic in GC_init() would
improve encapsulation, ease portability and binding to libgc, and also
maintain some sort of binary compatibility across libgc versions.

So my question is this: Why i

Assertion failure in GC_malloc_uncollectable: GC_ASSERT(hhdr -> hb_n_marks == 0)

Jan Wielemaker — 2012-05-02T09:36:05

Hi,

I'm experiencing assertion failures with GC_malloc_uncollectable() on a
big block (usually a few 100 Kb): GC_ASSERT(hhdr -> hb_n_marks == 0).

Now, I have to admit this is on a modified version (as discussed on this
list).  The version is based on a1467f2140f9db3408f6214137c7dc31f10d0bd9
(Jan 16 git version).  Using the unmodified version would require many
changes to the program :-(

This is merely a quick investigation to see whether this rings a bell
with someone. Platform is X64 Linux (Ubuntu). GC Config flags:
'--enable-threads=pthreads' '--enable-parallel-mark'
'--enable-large-config' '--enable-gc-assertions'

hhdr is this:

(gdb) p *hhdr
$1 = {hb_next = 0x0, hb_prev = 0x0, hb_block = 0x23ba000,
   hb_obj_kind = 2 '\002', hb_flags = 0 '\000', hb_last_reclaimed = 7,
   hb_sz = 196624, hb_descr = 196624, hb_large_block = 1 '\001',
   hb_map = 0x638f60, hb_n_marks = 1, hb_n_uncollectable = 0,
   _mark_byte_union = {_hb_marks = "\001", '\000' <repeats 255 times>, 
"\001",
     dummy = 1}}

Only one th

Fwd: Re[2]: PATCH: Add x32 support to boehm-gc

Ivan Maidanski — 2012-05-01T15:20:14

Hi H.J.,

I've applied your patches both to bdwgc and libatomic_ops (and both to master and release branches).

Regards.

Mon, 30 Apr 2012 16:44:32 -0700 "H.J. Lu" <hjl.tools-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>:
----------------

Problem with GC on FreeBSD

Vitaly Magerya — 2012-04-17T18:01:22

Hi, folks. A number of programs that use libgc fail on FreeBSD; I'm
not completely sure this is gc's fault, but it does fail it's own
disclaim_test, so I need help fixing that.

That was the short version. The long one is this. Starting with
FreeBSD 9.0 a number of ports that use libgc fail during build; the
ones I care about are STklos [1] and Gauche [2]. Both currently use
libgc 7.1, both segfault on startup inside GC_FreeBSDGetDataStart
(os_dep.c:1654; I can provide backtraces on request), and both
worked fine on FreeBSD 7.x and 8.x.

I tried updating libgc from the ancient 7.1 to 7.2-alpha6 and to
current git (from github.com/ivmai/bdwgc) -- this helps a little.
The programs don't fail immediately on startup, but STklos hangs
on one of it's unit tests (while testing threads), and Gauche crashes
while compiling (or loading?) a thread-related library (the crash
is not inside of libgc).

Now while I'm not completely sure the new problems are caused by
the garbage collector, here's one datapoint: libgc fails

Don't use __builtin_unwind_init() with clang

Niklas Therning — 2012-04-17T07:00:30

Hi,

I've had some problems with GC allocated memory being collected even 
though it is referenced by a CPU register. I'm using clang on mac os x:

$ clang -v
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

This is the clang that comes with XCode 4.2.1.

I've seen this problem when targeting both x86_64 and arm (iOS). It 
turns out that the __builtin_unwind_init() function on this clang 
version is a noop. It does nothing. I've disassembled the mach_dep.o 
generated by clang for both x86_64 and arm with and without the call to 
__builtin_unwind_init(). The assembly is identical.

Here's a patch that fixes this problem for me. It prevents 
HAVE_BUILTIN_UNWIND_INIT to be set if the compiler is clang:

diff -rupN bdwgc-20120327.orig/include/private/gcconfig.h 
bdwgc-20120327/include/private/gcconfig.h
--- bdwgc-20120327.orig/include/private/gcconfig.h      2012-03-27 
16:11:13.000000000 +0200
+++ bdwgc-20120327/include/private/gccon

Benchmarking options

David Terei — 2012-04-05T22:30:36

Hi all,

I'm currently making some changes to the GC as part of a OS research
project at Stanford and was wondering what is the best way to
benchmark the GC? There is this page:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_bench.html but it
seems to indicate its mostly useful as a test program than a serious
benchmark.

Cheers,
David

gc make fail on Solaris 10 x86_64 with gcc-3.* & -m64 option

Kiyoshi KANAZAWA — 2012-03-25T11:42:58

Hello,

I tried to build 64bits gc-7.1 on Solaris 10 x86_64. but failed with message:
libatomic_ops/src/atomic_ops.h:197,
                 from ./include/private/gc_locks.h:30,
                 from ./include/private/gc_priv.h:85,
                 from alloc.c:19:
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:9:23: xmmintrin.h: No such file or directory
In file included from libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:37,
                 from libatomic_ops/src/atomic_ops.h:197,
                 from ./include/private/gc_locks.h:30,
                 from ./include/private/gc_priv.h:85,
                 from alloc.c:19:
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: warning: data definition has no type or storage class
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: error: syntax error before "double_ptr_storage"
libato

Status of the MacOS ports

2012-03-15T17:59:54

Dear Ivan,

I'm a little bit lost with the current versions of the collector. So far
we have had problem using the collector under MacOS 10.7 either compiled
with the regular GCC compiler or with LLVM-GCC. 

Could you summarize the status of the port? Is it now fully operational
under that OS version (and the former ones too)?

Thanks in advance for your clarifications.

Regards,

Rental Services (TEST & MEASUREMENT Instruments) - Tue Mar 06 18:28:09 GMT+08:00 2012

Tech-Rentals (Malaysia) Sdn. Bhd. — 2012-03-06T10:28:09

_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

(no subject)

Ivan Maidanski — 2012-03-06T13:31:21

Hi Kai,

I found recent commit to gcc/boehmgc regarding DLL_EXPORT handling -
https://github.com/ivmai/bdwgc/commit/6488760cc5b3829bd81d442f0e95cd248f9bcf4d

1. Could you please describe the purpose - AFAIK, GCC (at least Cygwin port) could create dll exporting functions even if they are not tagged with dllexport.
2. I tried to apply your patch (slightly modified - shown below) to recent GC and failed because -D DLL_EXPORT is specified only during compilation of libgc modules but not during compilation of tests causing "GC_print_stats undefined" error.

My alternative solution is to define GC_DLL if --enable-shared with --disable-static.
See commit https://github.com/ivmai/bdwgc/commit/505b041e15e243e0f33540363ac40797e2bff4f4

Regards.

PS. The patch that failed for the recent BDWGC:

diff --git a/include/gc_config_macros.h b/include/gc_config_macros.h
index b340f49..d4b7231 100644
--- a/include/gc_config_macros.h
+++ b/include/gc_config_macros.h
< at >< at > -164,8 +164,9 < at >< at >
 # endif
 #endif /* _WIN32_WCE */

-#if de

move_disappearing_link to release?

Andy Wingo — 2012-03-03T19:07:54

Hi,

GC_move_disappearing_link is performance boost to some applications that
I work on.  It's a fairly simple extension to the existing disappearing
link facility.  Any chance of it appearing in the next release?

FWIW, I tried the following on the release branch:

  git cherry-pick c3cc33f676502406416cb3caac13fab3a8fbc49b..5c53923e5f8d63b789bf0ecaad0776fe1abbdf12

And that landed all of the disappearing links patches, with no
conflicts.

Regards,

Andy

Building on OS X: Autotools vs pkg-config issues

Bruce Mitchener — 2012-03-02T05:28:07

Hello,

It would be really nice if Boehm could build out of the box on Mac OS X
without having to install updated autotools and pkg-config.  A quick check
seems to show that it could work with the version of autotools shipped on
OS X, with the exception of the usage of pkg-config.

One fix would be to put a copy of pkg.m4 in bdwgc/m4/ next to the
gc_set_version.m4 and distribute that yourself.  With that and changing the
AC_PREREQ to use 2.61 for both the GC and libatomic_ops, things appear to
work.  There's an argument to be made that shipping pkg.m4 here is bad, but
the current situation also seems a bit bad.

Another fix might be to not use pkg-config or to support some way of not
using it, but that seems like more work.

Is there another way that we could get this to where it works out of the
box on a roughly out of the box XCode installation?

The background for this is that in Open Dylan (http://opendylan.org/), we
have various build / packaging issues where we'd rather just pull in Boehm
via a git sub

Is GC_init callable multiple times?

Alex — 2012-03-01T20:01:56

Hi,

Is the GC_init() function callable multiple times? In my case, I'm
wrapping libgc in a class in an OO language, so it is easiest to
simply call GC_init() in the constructor for said class. This means
that it may well be called multiple times, however. Looking at the
GC_init() and GC_init_inner() implementations in misc.c suggests that
at least some sanity checks are done to ensure double-initialization
doesn't happen even if GC_init() is called multiple times. However,
this behavior doesn't seem to be documented anywhere, so I'm unsure
whether calling GC_init() multiple times is considered sane and is
part of the interface?

Thanks in advance,
Alex