Henryk Michalewski | 18 Mar 01:02 2015
Picon

[Gc] A student assignment based on bdwgc

I am running a CS 101 class at the CS department of the University of
Warsaw. This class is focused on the C language. I like the idea of
making a student software project based on bdwgc  and contemplated
options such as
 - implementation of alternative gc algorithm
 - some optimizations/improvements in the current code
 - building an additional tool conceptually related to bdwgc
The final project should not exceed 2000-3000 lines.

Maybe this is a stupid idea in the sense that in your view this is a
too tough assignment - please feel free to inform me about it.
Otherwise, I would be glad to hear some specific recommendations from
the authors!

Yours, Henryk Michalewski

--

-- 
http://www.mimuw.edu.pl/~henrykm
Ivan Maidanski | 17 Feb 10:48 2015
Picon

Re: [Gc] [bdwgc] Build failed on NetBSD/sparc64, Makefile problem (#65)

Hello Tobias,

Could you please submit a patch for configure.

For historical reasons C files remain in rootdir while others (required only for some targets) are moved to src folder.

--

Mon, 16 Feb 2015, 11:04 +03:00 from Tobias Nygren <notifications <at> github.com>:

Hi,
When building with ./configure && make on NetBSD/sparc64  the build failed with:
>make[1]: don't know how to make sparc_mach_dep.lo. Stop
This fixed the problem:
gc-7.4.2$ mv src/* .
gc-7.4.2$ rmdir src
(Why are the sparc assembler files alone in the src subdirectory?)

Reply to this email directly or  view it on GitHub .

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Andrew Pinski | 11 Feb 07:03 2015
Picon

[Gc] [PATCH] Implement boehm-gc for AARCH64:ILP32

Hi,
  This is a simple patch which allows all of the boehm-gc testsuite
that is included with GCC to pass for AARCH64:ILP32.
Basically we need to set CPP_WORDSZ to 32 and the alignment to 4 so we
detect pointers correctly.

OK for GCC?  Bootstrapped and tested for aarch64-linux-gnu with no
regressions and many libjava testcases now pass.

OK for boehm-gc upstream?  I don't have write access to upstream
sources though, if approved there please apply it also.

Thanks,
Andrew Pinski

GCC ChangeLog:
    * include/private/gcconfig.h (CPP_WORDSZ): Correct for AARCH64:ILP32.
    (ALIGNMENT): Correct for AARCH64:ILP32.
commit 7d15d08c61991c3f7fea822fb567106dde83a166
Author: Andrew Pinski <apinski <at> cavium.com>
Date:   Wed Feb 11 02:35:45 2015 +0000

    Fix boehm-gc for AARCH64:ILP32

    * include/private/gcconfig.h (CPP_WORDSZ): Correct for AARCH64:ILP32.
    (ALIGNMENT): Correct for AARCH64:ILP32.

diff --git a/boehm-gc/include/private/gcconfig.h b/boehm-gc/include/private/gcconfig.h
index 7e081d9..049e24c 100644
--- a/boehm-gc/include/private/gcconfig.h
+++ b/boehm-gc/include/private/gcconfig.h
 <at>  <at>  -1854,9 +1854,14  <at>  <at> 
 # endif

 # ifdef AARCH64
-#   define CPP_WORDSZ 64
 #   define MACH_TYPE "AARCH64"
-#   define ALIGNMENT 8
+#   ifdef __ILP32__
+#     define CPP_WORDSZ 32
+#     define ALIGNMENT 4
+#   else
+#     define CPP_WORDSZ 64
+#     define ALIGNMENT 8
+#   endif
 #   ifndef HBLKSIZE
 #     define HBLKSIZE 4096
 #   endif
diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h
index aa80d53..989a734 100644
--- a/include/private/gcconfig.h
+++ b/include/private/gcconfig.h
 <at>  <at>  -2020,9 +2020,14  <at>  <at> 
 # endif

 # ifdef AARCH64
-#   define CPP_WORDSZ 64
 #   define MACH_TYPE "AARCH64"
-#   define ALIGNMENT 8
+#   ifdef __ILP32__
+#     define CPP_WORDSZ 32
+#     define ALIGNMENT 4
+#   else
+#     define CPP_WORDSZ 64
+#     define ALIGNMENT 8
+#   endif
 #   ifndef HBLKSIZE
 #     define HBLKSIZE 4096
 #   endif
_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Tom de Vries | 19 Jan 10:09 2015

[Gc] boehm-gc.c/gctest.c spurious failure

Hi,

FYI, with gcc trunk on x86_64 Linux, I ran into PR64042: 'FAIL: 
boehm-gc.c/gctest.c -O2 execution test'. ( 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 )

The testcase gctest fails spuriously, a couple of times per 1000 runs.

The failure has been reproduced by others, also on Darwin.

Any information on this is appreciated.

Thanks,
- Tom
Hans Aberg | 2 Jan 23:16 2015
Picon

[Gc] C++ global objects initialization

FYI: C++ global objects initialization on platforms where GC_INIT() is necessary, as on OS X 10.10, there
is the problem that the latter must be called before memory allocations by GC_malloc(). So it can’t be in main().

I found a workaround, that perhaps might be used to avoid GC_INIT() in the API (disregarding complications
with multiple allocators): the GC_malloc() replacement calls a pointer which first is an
initialization function, but is then changed to just the old GC_malloc().

In the code below, the GC_malloc() replacement is called gc_f. Then it seems to work in C++11 with the
operator new() replacements below, also with standard library containers global objects.

----
typedef void* (*malloc_ptr)(size_t);

extern malloc_ptr gc_f;

void* gc_uninitialized(size_t n) {
  gc_f = &GC_malloc;
  GC_INIT();
  return gc_f(n);
}

malloc_ptr gc_f = gc_uninitialized;

void* operator new(std::size_t n) { return gc_f(n); }
void operator delete(void*) noexcept {}
void* operator new[](std::size_t n) { return gc_f(n); }
void operator delete[](void*) noexcept {}
----
_______________________________________________
bdwgc mailing list
bdwgc <at> lists.opendylan.org
https://lists.opendylan.org/mailman/listinfo/bdwgc
John Leung | 29 Dec 22:58 2014

[Gc] cordtest, gctest FAIL on OSX

cordtest, gctest FAIL on OSX in make check

sys info:
OSX 10.9.2
Xcode 4.5.2
Please let me know what other information I need to provide.
thank you.


> make check
...
/Applications/Xcode.app/Contents/Developer/usr/bin/make  check-TESTS
./test-driver: line 107: 11117 Abort trap: 6           "$ <at> " > $log_file 2>&1
FAIL: cordtest
./test-driver: line 107: 11137 Abort trap: 6           "$ <at> " > $log_file 2>&1
FAIL: gctest
PASS: leaktest
PASS: middletest
PASS: smashtest
PASS: hugetest
PASS: realloc_test
PASS: staticrootstest
PASS: threadleaktest
PASS: threadkey_test
PASS: subthreadcreate_test
PASS: initsecondarythread_test
PASS: disclaim_test
PASS: disclaim_bench
make[5]: Nothing to be done for `all-am'.
============================================================================
Testsuite summary for gc 7.5.0
============================================================================
# TOTAL: 14
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to bdwgc <at> lists.opendylan.org
============================================================================
make[3]: *** [test-suite.log] Error 1
make[2]: *** [check-TESTS] Error 2
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1




> cat ./test-suite.log
================================
   gc 7.5.0: ./test-suite.log
================================

# TOTAL: 14
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: cordtest
==============


FAIL: gctest
============

pthread_attr_setstacksize failed, error=22
Test failed

_______________________________________________
bdwgc mailing list
bdwgc@...
https://lists.opendylan.org/mailman/listinfo/bdwgc
Niklas Therning | 22 Dec 08:41 2014

[Gc] iOS ARM64 (Aarch64) support

Hi,

We've made a first attempt [1] at porting the GC to iOS ARM64
(Aarch64) and so far it seems to be working fine. Wanted to check
whether someone else is working on this as well?

One initial problem we had was what we'd set STACKBOTTOM to. The value
for iOS 32-bit seemed totally arbitrary. But AFAICS, for Darwin, the
actual value for STACKBOTTOM is ignored and instead it's set to the
expression (ptr_t)pthread_get_stackaddr_np(pthread_self()) in
os_dep.c. Can someone please confirm that this is indeed what happens
for OS X/iOS?

Please let me know whether you'd be interested in merging this and
I'll send a PR.

[1] https://github.com/robovm/bdwgc/commit/a583a080fd9bd57927190dfa090ad281ddc931d5

Regards,
Niklas
RoboVM
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

Gmane