headers
Boehm, Hans | 8 Feb 16:56
Picon
Favicon

RE: about bitmap marking

[Copying response to gc mailing list.]

 

6.8 is old at this point, but this hasn’t changed much in 7.2alpha6.

 

The collector always stores mark bits in a map off to the side.  When I last looked at this ages ago, that seemed to be a clear win.  We need to look up a page descriptor for the object being marked in any case.  Thus the overhead is smaller than it would probably be for a non-conservative collector.  Having the mark bit in the object, or even on the same page, would mean accessing pages containing pointer-free objects during a GC.  In my experience, in well-tuned applications, a large fraction of the heap is pointer-free.  The GC could often touch twice as many pages during a GC with the mark bits in the objects.

 

An ancient version of the GC stored mark bits at the beginning of each page.  That potentially  causes other cache-related problems.  All mark bits contend for a small fraction of the cache.

 

The GC allocates memory from a free-list, but free-lists are built only a page at a time, when needed.  Building the free-list will force memory into the cache, but the hope is that it will still be there when the object is allocated by the client.

 

Hans

 

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.org
Subject: about bitmap marking

 

Dear Boehm:

 

I'm sorry about my poor English.

 

I would like to hear about boehm gc.

 

Boehm gc(gc6.8) uses Bitmap marking as default?

 

In Boehm gc, bitmap marking rules out storing mark-bits in object headers?(move mark-bits to other area)

 

Does Boehm gc get memory area from a freelist when allocate memory?

 

I'm waiting for your reply eagerly.

 

Best regards.

 

 

Li Jun

Univ. of Tsukuba

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Permalink | Reply | 4 comments |
headers
François-Xavier Thomas | 6 Feb 08:52
Picon
Gravatar

Tests fail on OS X

Hi,

I'm currently trying to install bdw-gc as a dependency for TeXmacs
under OS X Lion, using XCode-provided tools, resulting in a failure to
run make check.

The MacPorts version (using standard GCC built from source) works, but
I would really love to use only tools provided by XCode since it
really is a pain to have to install/compile/update other GCCs...

You can check this thread on the Homebrew repo for more reports from
other users (afaik, most of them are trying to install w3m, but the
issue is the same) : https://github.com/mxcl/homebrew/issues/8609

Versions :
* BDW-GC 7.1 and 7.2alpha6
* Compilers: LLVM-GCC 4.2 and Clang-GCC 3.0 from XCode 4.2
* OS: OS X Lion 10.7.2

My make check output is below, although I don't know whether it'll be
useful or not...

make  check-TESTS
Switched to incremental mode
Emulating dirty bits with mprotect/signals
typed alloc failed at 289
Test failed
/bin/sh: line 1: 90371 Abort trap: 6           ${dir}$tst
FAIL: gctest
Leaked composite object at 0x105621ee0 (tests/leak_test.c:12, sz=13, NORMAL)

Leaked composite object at 0x105621f20 (tests/leak_test.c:12, sz=12, NORMAL)

Leaked composite object at 0x105621f60 (tests/leak_test.c:12, sz=11, NORMAL)

Leaked composite object at 0x105621fa0 (tests/leak_test.c:12, sz=10, NORMAL)

Leaked composite object at 0x105621fe0 (tests/leak_test.c:12, sz=9, NORMAL)

Leaked composite object at 0x105620f20 (tests/leak_test.c:12, sz=8, NORMAL)

Leaked composite object at 0x105620f50 (tests/leak_test.c:12, sz=7, NORMAL)

Leaked composite object at 0x105620f80 (tests/leak_test.c:12, sz=6, NORMAL)

Leaked composite object at 0x105620fb0 (tests/leak_test.c:12, sz=5, NORMAL)

Leaked composite object at 0x105620fe0 (tests/leak_test.c:12, sz=4, NORMAL)

GC_debug_free: found smashed location at 0x105620fa8 in or near object
at 0x105620fb0 (0b:0, sz=0)
GC_debug_free: found smashed location at 0x105620f78 in or near object
at 0x105620f80 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105620f48 in or near object
at 0x105620f50 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105620f18 in or near object
at 0x105620f20(<smashed>, appr. sz = 9)
GC_debug_free: found smashed location at 0x105621fd8 in or near object
at 0x105621fe0 (@b:0, sz=0)
GC_debug_free: found smashed location at 0x105621f98 in or near object
at 0x105621fa0 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105621f58 in or near object
at 0x105621f60 (?b:0, sz=0)
GC_debug_free: found smashed location at 0x105621f18 in or near object
at 0x105621f20 (EMPTY(smashed?):0, sz=0)
GC_debug_free: found smashed location at 0x105621ed8 in or near object
at 0x105621ee0(<smashed>, appr. sz = 25)
/bin/sh: line 1: 90390 Segmentation fault: 11  ${dir}$tst
FAIL: leaktest
Final heap size is 253943808
PASS: middletest
GC_check_heap_block: found smashed heap objects:
 0x108e5ffe8 in or near object at 0x108e5ffc0 (tests/smash_test.c:22, sz=40)

GC_check_heap_block: found smashed heap objects:
 0x108ed2f98 in or near object at 0x108ed2f70 (tests/smash_test.c:22, sz=40)
 0x108e5ffe8 in or near object at 0x108e5ffc0 (tests/smash_test.c:22, sz=40)

PASS: smashtest
PASS: hugetest
FAIL: staticrootstest
Leaked composite object at 0x10e0f1fe0 (tests/thread_leak_test.c:12,
sz=4, NORMAL)

Leaked composite object at 0x10e0f1fb0 (tests/thread_leak_test.c:12,
sz=4, NORMAL)

Leaked composite object at 0x10e0f1d40 (tests/thread_leak_test.c:12,
sz=4, NORMAL)

Leaked composite object at 0x10e0f1e30 (tests/thread_leak_test.c:12,
sz=4, NORMAL)

Leaked composite object at 0x10e0f1f80 (tests/thread_leak_test.c:12,
sz=4, NORMAL)

PASS: threadleaktest
PASS: threadkey_test
PASS: initsecondarythread
usage: test_cpp number-of-iterations
Assuming 10 iters
Starting iteration 1
Assertion failure in tests/test_cpp.cc, line 116: nFreed <= nAllocated
&& nFreed >= .8 * nAllocated
FAIL: test_cpp
==================================
4 of 10 tests failed
Please report to Hans.Boehm@...
==================================

Any ideas?

--

-- 
François-Xavier Thomas
Elève ingénieur à Télécom ParisTech
Permalink | Reply | 0 comments |
headers
Ivan Maidanski | 7 Feb 08:26
Picon

Re[2]: [bdwgc] Tests fail on Mac OS X Lion (#11)

Hi,

Could you please preprocess the code both with -D_XOPEN_SOURCE and without and compare the difference?

06 02 2012, 23:50 François-Xavier Thomas <reply+i-3102864-c255b8ee79ec3c6f466471f7020ef26926aebfb5-460469@...>:
> 1. The previous package manager had added `-D_XOPEN_SOURCE` to the CPP/CXXFLAGS, so I assumed it was
necessary to build the package under OS X. I still don't know what it does, but everything went fine when I
removed it.
> 2. OK, that's good to know. Did it fail as well without the optimizations?
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/ivmai/bdwgc/issues/11#issuecomment-3835425
>
Permalink | Reply | 0 comments |
headers
Ivan Maidanski | 6 Feb 15:03
Picon

Re[2]: [bdwgc] Tests fail on Mac OS X Lion (#11)

Hi,

1. Ok. Let us know the problem root then.

2. I tried libatomic_ops make check CC=clang on Ubuntu 11 x86 and it failed in test_stack (with -O2 or
higher). So, some problem exists in libatomic_ops.

clang version 1.1 (branches/release_27)
Target: i386-pc-linux-gnu
Thread model: posix

Regards.

06 02 2012, 17:04 François-Xavier Thomas <reply+i-3102864-c255b8ee79ec3c6f466471f7020ef26926aebfb5-460469@...>:
> Wow... I just tried building it manually from source, and tests passed OK, so Homebrew must be messing with
the checks. Sorry to have bothered you guys, I'm going to look into it. I hope I'll be able to fix it soon!
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/ivmai/bdwgc/issues/11#issuecomment-3828047
>
Permalink | Reply | 0 comments |
headers
Ivan Maidanski | 6 Feb 13:56
Picon

Job dedicated to BDWGC improvement

Hi everybody,

I wonder is there anybody on the list from Russia (or exUSSR) willing to bug-fix, optimize and integrate BDW
GC on a full-time long-term (at least 1 year) basis?

Regards.
Permalink | Reply | 0 comments |
headers
Ivan Maidanski | 6 Feb 09:06
Picon

Re: [bdwgc] Tests fail on Mac OS X Lion (#11)

Hi,

1. Could you please make check using latest bdwgc+libatomic_ops source (master or release branch), first?
2. Is this a regression? (i.e. is there any GC v7 release or snapshot which works ok?)

Regards.

06 02 2012, 04:47 François-Xavier Thomas <reply+i-3102864-c255b8ee79ec3c6f466471f7020ef26926aebfb5-460469@...>:
> Hi,
> 
> I'm currently trying to install bdw-gc as a dependency for TeXmacs under OS X Lion,  using LLVM-GCC (from
XCode 4.2).
> 
> The standard MacPorts version (using standard GCC built from source) works, but I would really love to use
only tools provided by XCode since it really is a pain to have to install/compile/update other GCCs...
> 
> You can check this thread on the Homebrew repo for more reports from other users : https://github.com/mxcl/homebrew/issues/8609
> 
> My *make check* output is below, although I don't know whether it'll be useful or not...
> 
> ```
> make  check-TESTS
> Switched to incremental mode
> Emulating dirty bits with mprotect/signals
> typed alloc failed at 289
> Test failed
> /bin/sh: line 1: 90371 Abort trap: 6           ${dir}$tst
> FAIL: gctest
> Leaked composite object at 0x105621ee0 (tests/leak_test.c:12, sz=13, NORMAL)
> 
> Leaked composite object at 0x105621f20 (tests/leak_test.c:12, sz=12, NORMAL)
> 
> Leaked composite object at 0x105621f60 (tests/leak_test.c:12, sz=11, NORMAL)
> 
> Leaked composite object at 0x105621fa0 (tests/leak_test.c:12, sz=10, NORMAL)
> 
> Leaked composite object at 0x105621fe0 (tests/leak_test.c:12, sz=9, NORMAL)
> 
> Leaked composite object at 0x105620f20 (tests/leak_test.c:12, sz=8, NORMAL)
> 
> Leaked composite object at 0x105620f50 (tests/leak_test.c:12, sz=7, NORMAL)
> 
> Leaked composite object at 0x105620f80 (tests/leak_test.c:12, sz=6, NORMAL)
> 
> Leaked composite object at 0x105620fb0 (tests/leak_test.c:12, sz=5, NORMAL)
> 
> Leaked composite object at 0x105620fe0 (tests/leak_test.c:12, sz=4, NORMAL)
> 
> GC_debug_free: found smashed location at 0x105620fa8 in or near object at 0x105620fb0 (0b:0, sz=0)
> GC_debug_free: found smashed location at 0x105620f78 in or near object at 0x105620f80
(EMPTY(smashed?):0, sz=0)
> GC_debug_free: found smashed location at 0x105620f48 in or near object at 0x105620f50
(EMPTY(smashed?):0, sz=0)
> GC_debug_free: found smashed location at 0x105620f18 in or near object at 0x105620f20(<smashed>,
appr. sz = 9)
> GC_debug_free: found smashed location at 0x105621fd8 in or near object at 0x105621fe0 (@b:0, sz=0)
> GC_debug_free: found smashed location at 0x105621f98 in or near object at 0x105621fa0
(EMPTY(smashed?):0, sz=0)
> GC_debug_free: found smashed location at 0x105621f58 in or near object at 0x105621f60 (?b:0, sz=0)
> GC_debug_free: found smashed location at 0x105621f18 in or near object at 0x105621f20
(EMPTY(smashed?):0, sz=0)
> GC_debug_free: found smashed location at 0x105621ed8 in or near object at 0x105621ee0(<smashed>,
appr. sz = 25)
> /bin/sh: line 1: 90390 Segmentation fault: 11  ${dir}$tst
> FAIL: leaktest
> Final heap size is 253943808
> PASS: middletest
> GC_check_heap_block: found smashed heap objects:
>  0x108e5ffe8 in or near object at 0x108e5ffc0 (tests/smash_test.c:22, sz=40)
> 
> GC_check_heap_block: found smashed heap objects:
>  0x108ed2f98 in or near object at 0x108ed2f70 (tests/smash_test.c:22, sz=40)
>  0x108e5ffe8 in or near object at 0x108e5ffc0 (tests/smash_test.c:22, sz=40)
> 
> PASS: smashtest
> PASS: hugetest
> FAIL: staticrootstest
> Leaked composite object at 0x10e0f1fe0 (tests/thread_leak_test.c:12, sz=4, NORMAL)
> 
> Leaked composite object at 0x10e0f1fb0 (tests/thread_leak_test.c:12, sz=4, NORMAL)
> 
> Leaked composite object at 0x10e0f1d40 (tests/thread_leak_test.c:12, sz=4, NORMAL)
> 
> Leaked composite object at 0x10e0f1e30 (tests/thread_leak_test.c:12, sz=4, NORMAL)
> 
> Leaked composite object at 0x10e0f1f80 (tests/thread_leak_test.c:12, sz=4, NORMAL)
> 
> PASS: threadleaktest
> PASS: threadkey_test
> PASS: initsecondarythread
> usage: test_cpp number-of-iterations
> Assuming 10 iters
> Starting iteration 1
> Assertion failure in tests/test_cpp.cc, line 116: nFreed <= nAllocated && nFreed >= .8 * nAllocated
> FAIL: test_cpp
> ==================================
> 4 of 10 tests failed
> Please report to Hans.Boehm@...
> ==================================
> ```
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/ivmai/bdwgc/issues/11
>
Permalink | Reply | 0 comments |
headers
Ivan Maidanski | 26 Jan 10:01
Picon

Re[3]: [Gc] --enable-gc-assertions bug report

Hi Daniel,

Merged to master with minor comment adjustment.
(I'll also merge it to "release" branch).

Regards.

26 01 2012, 06:30 "Grayson, Daniel R." <dan@...>:
> Here you go.   It works at this end.
> 
> diff -ur
/Users/dan/src/M2/trunk/M2/BUILD/dan/builds.tmp/mac64.debug/libraries/gc/tmp/gc-7.3alpha1.2012.01.23/include/gc.h gc-7.3alpha1.2012.01.23/include/gc.h
> ---
/Users/dan/src/M2/trunk/M2/BUILD/dan/builds.tmp/mac64.debug/libraries/gc/tmp/gc-7.3alpha1.2012.01.23/include/gc.h	2012-01-23
16:52:39.000000000 -0600
> +++ gc-7.3alpha1.2012.01.23/include/gc.h	2012-01-25 20:27:21.000000000 -0600
> @@ -468,7 +468,7 @@
>  GC_API void GC_CALL GC_clear_roots(void);
> 
>  /* Add a root segment.  Wizards only.                                   */
> -/* The segment (referred to by low_address) must be pointer-aligned.    */
> +/* The segment (referred to by low_address) need not be pointer-aligned.*/
>  /* low_address must not be greater than high_address_plus_1.            */
>  GC_API void GC_CALL GC_add_roots(void * /* low_address */,
>                                   void * /* high_address_plus_1 */);
> diff -ur
/Users/dan/src/M2/trunk/M2/BUILD/dan/builds.tmp/mac64.debug/libraries/gc/tmp/gc-7.3alpha1.2012.01.23/mark_rts.c gc-7.3alpha1.2012.01.23/mark_rts.c
> ---
/Users/dan/src/M2/trunk/M2/BUILD/dan/builds.tmp/mac64.debug/libraries/gc/tmp/gc-7.3alpha1.2012.01.23/mark_rts.c	2012-01-23
16:52:39.000000000 -0600
> +++ gc-7.3alpha1.2012.01.23/mark_rts.c	2012-01-25 19:58:10.000000000 -0600
> @@ -156,11 +156,10 @@
>  {
>      struct roots * old;
> 
> -    /* Adjust and check range boundaries for safety */
> -    GC_ASSERT((word)b % sizeof(word) == 0);
> -    e = (ptr_t)((word)e & ~(sizeof(word) - 1));
>      GC_ASSERT(b <= e);
> -    if (b == e) return;  /* nothing to do? */
> +    b = (ptr_t)(((word)b + sizeof(word) - 1) & ~(sizeof(word) - 1)); /* round b  up  to word boundary */
> +    e = (ptr_t)((word)e & ~(sizeof(word) - 1));			     /* round e down to word boundary */
> +    if (b >= e) return;  /* nothing to do */
> 
>  #   if defined(MSWIN32) || defined(MSWINCE) || defined(CYGWIN32)
>        /* Spend the time to ensure that there are no overlapping */
> 
> On Jan 25, 2012, at 3:30 PM, Ivan Maidanski wrote:
> 
> > Hi Daniel,
> >
> > Could you please compose the fix? (I think the best solution would be to adjust begin in
GC_add_roots_inner (adjusting the comment in gc.h))
> >
> > Regards.
> >
> > 26 01 2012, 01:16 "Grayson, Daniel R." <dan@...>:
> >> Enabling --enable-gc-assertions under gcc 4.6.2 in Mac OS X 10.7
> >> causes all tests to fail.  The reason is the assertion in GC_add_roots_inner
> >> that tests whether the address is on an word size 8 byte boundary.  But the
> >> linker generated address "start" can fail that test, and it's added
> >> in GC_dyld_image_add.  The value was 0x100122a44.
> >>
> >> _______________________________________________
> >> Gc mailing list
> >> Gc@...
> >> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
>
Permalink | Reply | 0 comments |
headers
Grayson, Daniel R. | 25 Jan 22:10
Picon
Favicon
Gravatar

--enable-gc-assertions bug report

Enabling --enable-gc-assertions under gcc 4.6.2 in Mac OS X 10.7
causes all tests to fail.  The reason is the assertion in GC_add_roots_inner
that tests whether the address is on an word size 8 byte boundary.  But the
linker generated address "start" can fail that test, and it's added
in GC_dyld_image_add.  The value was 0x100122a44.
Permalink | Reply | 1 comment |
headers
Ivan Maidanski | 25 Jan 19:50
Picon

Re[2]: [bdwgc] Add disclaim callback and a "finalized" object kind (#5)

Hi Petter,

I don't mind, I think a client would rarely need many object kind.

The opposite (documenting that cd  is GC-invisible) - I don't like since other "cd" (in other APIs, e.g., in
normal finalization) are scanned by GC. This would require a separate table of "cd" (for every kind) and
GC_push_all for that table.

So, to repeat, your idea about cd removal seems to me the best solution (it's ok to change the API as was added
after the latest GC release).

Regards.

25 2012, 22:09 Petter Urkedal <reply+i-1676083-23a7200ee85ed491d4b78d17b755365da52f4e23-460469@...>:
> Good catch, I didn't notice that GC_obj_kinds were excluded from the root set.  I think documenting may be
ok, since object kinds is something one sets up once and for all, so one may use uncollected or static
storage.  In fact, it wouldn't be that bad to remove the cd for the same reason, and let client code use a
separate entry point for each object kind if needed. Do you have an opinion?
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/ivmai/bdwgc/pull/5#issuecomment-3655634
>
Permalink | Reply | 0 comments |
headers
Ivan Maidanski | 25 Jan 14:22
Picon

Re[3]: [bdwgc] Add disclaim callback and a "finalized" object kind (#5)

Hi Petter,

Is "cd" passed to GC_register_disclaim_proc assumed to be GC-visible? If yes then GC_push_all should be
invoke for every GC_obj_kinds[i].ok_disclaim_cd. If no, there should be a note in the comment.

Regards.

17 01 2012, 20:27 Ivan Maidanski <ivmai@...>:
> Regarding pull requests vs merge manually: seems it doesn't matter for me as I see your commits on Network
-> Fork Queue panel (allowing me to apply it into some branch).
> 
> 13 01 2012, 22:45 Petter Urkedal <reply+i-1676083-23a7200ee85ed491d4b78d17b755365da52f4e23-460469@...>:
> > On 2012-01-13, Ivan Maidanski wrote:
> > > Hi Petter,
> > >
> > > On an occasion, I've launched disclaim_test.c  without -DALL_INTERIOR_POINTERS (for both GC and
test) and it failed. I haven't analyzed the reason, right now my question is: Does finalized_malloc
feature require ALL_INTERIOR_POINTERS (in this case, please add conditional #error), or just the test
require it (then please add GC_set_all_interior_pointers call).
> > >
> > > Cmd (that i've launched, I haven't tried it using make):
> > > gcc -I include -DENABLE_DISCLAIM --include extra/gc.c tests/disclaim_test.c
> >
> > Hi Ivan,
> >
> > Yes, the finalized object allocated displaces the returned pointer by
> > one word, to hide the finalizer stored in the first word.  I just sent a
> > pull request.
> >
> > BTW, do you prefer to merge manually or do you like the pull request
> > feature?  (I don't have experience on your end of it.)
> >
> > Petter
> >
> > ---
> > Reply to this email directly or view it on GitHub:
> > https://github.com/ivmai/bdwgc/pull/5#issuecomment-3484265
> >
Permalink | Reply | 0 comments |
headers
Jan Wielemaker | 24 Jan 15:48
Picon
Picon

GC_DEBUG and typed/kind?

Hi,

Partly related to my previous post, I see GC_DEBUG doesn't work both
for objects that are allocated with a type descriptor nor with a
user defined kind.

Checking dbg_mlc.c, it seems that adding debug support for the various
kinds all follows the same pattern.  Is there any reason why this
pattern cannot work for GC_generic_malloc() or GC_malloc_explicitly_typed()?

If this pattern should work, I get more relaxed using these features:
if I need the debug versions I'll write them (and submit the patch).

	Thanks --- Jan
Permalink | Reply | 0 comments |

Gmane