Hans Aberg | 30 Nov 23:44 2014
Picon

[Gc] OS X 10.10 install

I get, on OS X 10.10.1, a ./configure error [1] with gc-7.4.2: it can’t find libatomic_ops-7.4.2, which I
have installed on the system, nor does linking help.

1. ./configure
...
checking for dladdr... yes
checking sys/dg_sys_info.h usability... no
checking sys/dg_sys_info.h presence... no
checking for sys/dg_sys_info.h... no
checking for pkg-config... no
checking for ATOMIC_OPS... no
configure: error: libatomic_ops is required.  You can either install it on
                  your system, or fetch and unpack a recent version into the
                  source directory and link or rename it to libatomic_ops.
_______________________________________________
bdwgc mailing list
bdwgc <at> lists.opendylan.org
https://lists.opendylan.org/mailman/listinfo/bdwgc
Jean-Claude Beaudoin | 19 Nov 02:23 2014
Picon

[Gc] On Linux, BDWGC prefers sbrk() over mmap(), why is that so?

Hello BDWGC folks,

During a recent bug chase of mine I stumbled over the fact that, in its default configuration on Linux, this GC will always try to call sbrk() before falling back onto mmap() (see GC_unix_get_mem() et al. in os_dep.c).

This is despite the fact that I configure my copy with --enable-threads=posix.
My system operates in a context where there is a number of threads not under GC control along with the set of threads the GC do control. On Linux, brk()/sbrk() is NOT a thread-safe facility and calls to it from non-GC threads or from other application code (dlopen() is liberally used in this system) cannot be prevented.

Further more, non-GC threads are very likely to use malloc() et al. for their memory needs, and malloc() relies on brk()/sbrk() for (at least a good part of) its business. A clash of some sort between malloc and BDWGC on their respective use of brk()/sbrk() seems in my opinion to be very likely, is it not?

The use of mmap() alone (no brk()/sbrk()) seems to be hardcoded in include/private/gcconfig.h for a number of platform (IRIX, AIX, Solaris, etc) but not for Linux. Is there some fundamental reason for this?

BTW, access to the use of mmap() through the "configure" interface seem to have been intentionally removed at some point in the past. One needs to edit configure.ac in order to use the remnants of it.

Regards,

Jean-Claude Beaudoin


_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Rodrigo Kumpera | 8 Nov 18:16 2014
Picon

[Gc] STW usage of signals

Hey Guys,

The mono VM is running short of usable signals on some targets and we're going to do signal multiplexing.

We use the same signal based suspend/resume mechanism as bdwgc and I've been wondering on why sigwait was used instead of a semaphore to implement resume.

This decision was made way way in the past but maybe someone still remember the rationale for it?

--
Rodrigo

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Thomas Klausner | 27 Oct 16:12 2014
Picon

[Gc] gc, guile, and NetBSD

Hi!

I'm trying to get a usable guile-2.0.11 on NetBSD-7.99.1/x86_64.
guile-1.8.x works fine on the same system.

I'm using gc-7.4.2 from pkgsrc, which currently has no additional
patches. It is compiled with --enable-cplusplus and --disable-threads.
'make check' passes without errors.

The guile build fails with:

  GEN      guile-procedures.texi
GC_is_visible test failed
[1]   Broken pipe             cat alist.doc ar... |
      Abort trap (core dumped) GUILE_INSTALL_LO...

which is the first time that the linked guile binary is actually
executed.

The backtrace looks like this:
Core was generated by `guile'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f7ff4d0e2ca in _lwp_kill () from /usr/lib/libc.so.12
(gdb) bt
#0  0x00007f7ff4d0e2ca in _lwp_kill () from /usr/lib/libc.so.12
#1  0x00007f7ff4d0df55 in abort () at /archive/foreign/src/lib/libc/stdlib/abort.c:74
#2  0x00007f7ff7415d2b in GC_default_is_visible_print_proc () from /usr/obj/wip/guile2/work/.buildlink/lib/libgc.so.1
#3  0x00007f7ff7416031 in GC_is_visible () from /usr/obj/wip/guile2/work/.buildlink/lib/libgc.so.1
#4  0x00007f7ff786d479 in scm_storage_prehistory () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/libguile-2.0.so.22
#5  0x00007f7ff787bc7a in scm_i_init_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/libguile-2.0.so.22
#6  0x00007f7ff78c9b6a in scm_i_init_thread_for_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/libguile-2.0.so.22
#7  0x00007f7ff78c9b89 in with_guile_and_parent () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/libguile-2.0.so.22
#8  0x00007f7ff7414ca9 in GC_call_with_stack_base () from /usr/obj/wip/guile2/work/.buildlink/lib/libgc.so.1
#9  0x00007f7ff78ca0af in scm_with_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/libguile-2.0.so.22
#10 0x00007f7ff787bc3c in scm_boot_guile () from /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/libguile-2.0.so.22
#11 0x000000000040104d in main ()

The code that is running at that point is at
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/gc.c;h=13823c054cb0d08cbaf1ced5209c41d9857b8bd4;hb=HEAD#l623

I've talked with some guile developers on IRC, and they claim that
they are just using gc like intended, and that this is a problem in gc
on NetBSD, not in guile.

I'm out of my depth here, and hope that someone on this list has an
insight in what might be going wrong here and how to fix it.

Thanks,
 Thomas
Ivan Maidanski | 27 Oct 07:47 2014
Picon

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

Hi,

It depends - both are used:
#include <gc/cord.h> // it is assumed gc is installed

#include "cord.h" // you should specify -I option but no need to install gc

Regards,
Ivan

Thursday, 23 Oct 2014, 12:15 +03:00 from 张睿 <zrui16 <at> hotmail.com>:

Hi,

The point is that gc header files are installed into $(prefix)/include/gc. When I build my own programs, the compiler will not find them unless I specify -I$(prefix)/include/gc to it.

I would like to ask which of the two is preferred: 1) specify the include path when compiling; 2) write #include<gc/cord.h> instead of #include <cord.h> in the source so that I do not have to specify the include path explicitly.​ (The compiler does search $(prefix)/include for headers.)

“make test” works fine since it is working in the source directory, where everything is present.

发件人:   Ivan Maidanski
发送时间:  ‎2014‎年‎10‎月‎23‎日, ‎星期四 ‎16‎:‎30
收件人:   张睿
抄送:   bdwgc <at> lists.opendylan.org

Hi,

I fixed second issue -   https://github.com/ivmai/bdwgc/commit/b519011261256f8b5b0f3d9868536271c78b53f5
About 1st one, I don't completely understand it. "./configure && make test" compiles and executes cordtest.

Regards,
IIvan

Wed, 8 Oct 2014 16:00:29 +0000 from 张睿 <zrui16 <at> hotmail.com>:
>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 <at> lists.opendylan.org
> https://lists.opendylan.org/mailman/listinfo/bdwgc

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

[Gc] Fwd: Re: AArch64: Shareability domain for dmb st overly conservative (#11)

Forwarding to ML..

From: Ivan Maidanski <ivmai <at> mail.ru>
To: Yvan Roux <yvan.roux <at> linaro.org>, Hans Boehm <boehm <at> acm.org>
CC: ivmai/libatomic_ops <libatomic_ops <at> noreply.github.com>, ivmai/libatomic_ops <reply+i-46004519-50324839f75648d459559128d780ac126d37fdde-460469 <at> reply.github.com>, Boehm GC <bdwgc <at> lists.opendylan.org>
Date: Thu, 23 Oct 2014 12:36:39 +0400
Subject: Re: [libatomic_ops] AArch64: Shareability domain for dmb st overly conservative (#11)

Hi Yvan and Hans,

Is the proposed change correct for ARM64 AO_nop_write? What's about 32-bit ARM?

Thank you

Thu, 16 Oct 2014 09:08:26 -0700 from stevecapperlinaro <notifications <at> github.com>:

Hello,
In src/atomic_ops/sysdeps/gcc/aarch64.h, we have the following code:
__asm__ __volatile__("dmb st" : : : "memory");

This will target the system domain and thus be overly conservative as the CPUs will occupy the inner shareable domain.

Could this please be changed to:
__asm__ __volatile__("dmb ishst" : : : "memory");

That way the barriers will occupy the inner shareable domain.

Thanks,
Steve Capper





_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
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

Gmane