gmane.comp.programming.garbage-collection.boehmgc

Uninitialized GC_threads and dll_thread_table vars

Ivan Maidanski — 2008-10-06T20:46:58

Hi! Is it safe to place GC_threads (both on Unix and Win32) and dll_thread_table (on Win32) to "common" section (instead of "bss")? It seems to me that not... Bye.

GC minor fix for Win32

Ivan Maidanski — 2008-10-06T20:06:35

Hi! "excpt.h" file should be included even for non-Gnu compilers on MSWIN32 in mark.c (for GetExceptionCode macro to get defined). This is required at least for Watcom C (and doesn't hurt other Win32 compilers - VC++/IntelC++, Borland, DMC). The patch is attached. Bye. diff -ru bdwgc/mark.c updated/bdwgc/mark.c --- bdwgc/mark.c2008-09-26 14:01:50.000000000 +0400 +++ updated/bdwgc/mark.c2008-10-06 23:01:56.000000000 +0400 < at >< at > -19,7 +19,7 < at >< at > # include # include "private/gc_pmark.h" -#if defined(MSWIN32) && defined(__GNUC__) +#if defined(MSWIN32) # include #endif _______________________________________________ Gc mailing list Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

gc's embedded libatomic_ops

Rex Dieter — 2008-10-03T16:57:24

Just noticed the embedded copy of libatomic_ops. Any reason to *not* use a system-wide/external libatomic_ops? Any objections to my preparing patches to do that? :)

small bug libatomic_ops-1.2/src/atomic_ops/sysdeps/gcc/x86_64.h

Andrew Agno — 2008-10-03T15:40:39

While browsing the source of gc-7.1, I noticed that libatomic_ops-1.2/src/atomic_ops/sysdeps/gcc/x86_64.h has unsigned short as the return from AO_int_fetch_and_add_full instead of unsigned int (on line 99). Andrew.

stack problem

Romano Tenca — 2008-09-29T12:21:13

I use GC in a program which sometime call a recursive function which consume a large C stack. After the use of this function, when the C stack is back to a normal size, GC allocations and recycles becomes a lot more slow. To give an idea, here it is the output of a test program which reports the time used by 10 GC_gcollect() calls inside a recursive function: After 0 recursions 10 GC_gcollect() time is: 0.03125 After 5000 recursions 10 GC_gcollect() time is: 0.203125 After 10000 recursions 10 GC_gcollect() time is: 0.59375 After 15000 recursions 10 GC_gcollect() time is: 1.1875 After 20000 recursions 10 GC_gcollect() time is: 2.015625 After 25000 recursions 10 GC_gcollect() time is: 3.0625 Here are some heap values after the recursive function returns: Heap: 5505024 Free: 4296704 Used: 1208320 Collections: 61 Now i call again the recursive function: After 0 recursions 10 GC_gcollect() time is: 2.984375 After 5000 recursions 10 GC_gcollect() time is: 3.015625 After 10000 recursions 10 GC_gcollect() time is: 3.0625 After 15000 recursions 10 GC_gcollect() time is: 3.09375 After 20000 recursions 10 GC_gcollect() time is: 3.140625 After 25000 recursions 10 GC_gcollect() time is: 3.1875 Here are some heap values after the recursive function returns Heap: 5505024 Free: 4288512 Used: 1216512 Collections: 121 As you can see the Heap and Used memory is almost the same, but the time of GC_collect are very different. It seems to me that the GC looks at all the stack, also the not more used one. I do not know if this is a bug, but there is a way to tell GC to scan only the used stack? I use version 70a with thread_local_alloc and UNMAP under XP. Tests are done with only the main thread running. Romano Paolo Tenca

"Leaked composite object at",but the object was never allocated

Benjamin Smedberg — 2008-09-25T14:47:08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In my ongoing project attempting to use Boehm GC in Mozilla, I wanted to make sure that Boehm was scanning our memory correctly and that we weren't hiding any pointers unintentionally: so I hooked up Boehm in leak-detector mode. Fairly early in startup, I think during the first GC, Boehm reports a bunch of leaked objects of size 32. I tried turning on GC_DEBUG stack traces, but this object didn't have any debugging information (allocation stacktrace) recorded. So I went through and tried to find the allocation site using a debugger... Leaked composite object at 0x808c020 Leaked composite object at 0x808c040 Leaked composite object at 0x808c060 Leaked composite object at 0x808c080 ... all the way to 0x808c220 I tried breakpoing GC_allocobj, GC_generic_malloc_inner and several other functions, but none of these functions ever return an allocation at 0x808c020. In fact, the very first allocation returned is at 0x808dfe0. I'm worried that Boehm is reporting a leak for an object that never seems to have been allocated in the first place. So I went back and found where this address space was being first used, by breakpointing GC_add_to_heap. Address 808c020 is being mapped at the following stack: #0 GC_add_to_heap (p=0x808c000, bytes=131072) at ../../../src/memory/boehmgc/alloc.c:801 #1 0xf7fcbd68 in GC_expand_hp_inner (n=16) at ../../../src/memory/boehmgc/alloc.c:956 #2 0xf7fd8f85 in GC_init_inner () at ../../../src/memory/boehmgc/misc.c:706 #3 0xf7fd2e95 in GC_generic_malloc_inner (lb=351, k=2) at ../../../src/memory/boehmgc/malloc.c:112 #4 0xf7fd2f6a in GC_generic_malloc (lb=351, k=2) at ../../../src/memory/boehmgc/malloc.c:160 #5 0xf7fd3adf in GC_malloc_uncollectable (lb=351) at ../../../src/memory/boehmgc/mallocx.c:469 #6 0xf7fd2a3d in malloc (lb=352) at ../../../src/memory/boehmgc/malloc.c:320 #7 0x002d4cef in __fopen_internal () from /lib/libc.so.6 #8 0x002d72cc in fopen64 () from /lib/libc.so.6 #9 0x0069b234 in ?? () from /lib/libselinux.so.1 #10 0x0069d136 in ?? () from /lib/libselinux.so.1 #11 0x00278fc0 in ?? () from /lib/ld-linux.so.2 #12 0xf7bb69e0 in ?? () #13 0xffc1d708 in ?? () #14 0x0068d2b1 in _init () from /lib/libselinux.so.1 The address is consistent in my program, so I tried setting a debugger watchpoint on it. This block of memory is not written-to until after the GC reports it as leaked and calls GC_free on it. Any clues? Perhaps I can watch the header block associated with this allocation to find out when it's being set up? - --BDS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI26RsSSwGp5sTYNkRAhKPAJ4oGyKfrSM8KlGUkNvqnJLSOlhxNgCaA7CH kXl/4AeE7YcvRNqrEoD4xXA= =ofGA -----END PGP SIGNATURE-----

Per-type displacement

Ludovic Courtès — 2008-09-19T12:14:24

Hi, Guile's `struct' objects are such that they can have N extra words that are hidden from the application roughly as follows: void * make_struct (size_t n_extra, size_t user_size) { char *p = GC_MALLOC (n_extra + user_size); return p + n_extra; } Registering a displacement globally for each value of N_EXTRA may lead to excess memory retention, especially since most other Guile objects ("cells") are 2 or 4 word long. Ideally, I'd create a `GC_desc' and somehow specify valid displacements that apply specifically to this type, which the `gc_typed.h' API currently doesn't allow. Does that seem like a reasonable approach? Can it be approximated using the current API? Is it just that this allocation paradigm (returning a pointer in the middle of the object) is questionable? :-) Thanks, Ludo'.

interior pointers to large allocations

Benjamin Smedberg — 2008-09-16T20:54:03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear GC list: I have a problem with interior pointers that doesn't seem to be covered by the docs. I have pre-existing code which allocates a structure struct nsStringBuffer { bool mShared; size_t mLength; char mBuffer[1]; // arbitrary length }; The code then stores a pointer to mBuffer, instead of a pointer to the root allocation. I figured this would be ok, since interior pointers are being scanned. But I was having heap corruption and starting sprinkling calls to GC_is_valid_displacement into my code. I found that if the allocated size is larger than a hblk, GC_is_valid_displacement rejects all interior pointers, due to this line: http://hg.mozilla.org/users/bsmedberg_mozilla.com/gcmonkey/file/96af1e84dbaa/memory/boehmgc/ptr_chck.c#l143 * Am I misusing GC_is_valid_displacement? * Is this a bug in GC_is_valid_displacement * or are interior pointers to large allocations actually not recognized? - --BDS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0BzrSSwGp5sTYNkRAlgYAJ0dwq7GFxxa2TeCug+V47QCnyvwiACgi4qS gbI0OVXsp5776hsbIDYH8VM= =UKCR -----END PGP SIGNATURE-----

Using `MANUAL_VDB' and stubborns

Ludovic Courtès — 2008-09-16T20:06:04

Hi, By default, GC 7.1 uses `MPROTECT_VDB' on GNU/Linux (i386), in which case "stubborns" are ignored. I tried to compile GC with `MANUAL_VDB' but without success: since there's no `configure' option, I tried the attached patch, but "make check" then fails with an undefined reference to `async_set_pht_entry_from_index'---and indeed, that function isn't defined in `MANUAL_VDB'. Is this an indication that `MANUAL_VDB' is not recommended? :-) In the case of Guile (Scheme interpreter), a number of objects are immutable, and it's easy to instrument the interpreter to use `GC_malloc_stubborn ()' in these cases. Thus, it seems more appealing than the heavyweight mprotect/SIGSEGV machinery. What do you think? Thanks, Ludovic. _______________________________________________ Gc mailing list Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

[announce] GC documentation in Texinfo format

Marco Maggi — 2008-09-16T10:19:02

A new version of GC documentation in Texinfo format is available: Details for Tue Sep 16, 2008 ---------------------------- * Renamed "bohem" to "boehm" (damn! sorry HB).

Rv: Begginer, Windows, c++

Daniel C — 2008-09-15T20:16:22

Yahoo! Cocina Recetas prácticas y comida saludable http://ar.mujer.yahoo.com/cocina/

Unregistering the main thread

Ludovic Courtès — 2008-09-15T19:09:57

Hello, Guile has an API that allows a program to specify that a given thread is not going to cooperate for GC for some time. This is useful, e.g., when a thread enters a blocking system call and doesn't want to prevent other threads from allocating memory or collecting garbage while it's blocked: scm_without_guile (the_function_that_blocks, NULL); On the port of Guile to BDW-GC, I implement it using `GC_unregister_my_thread ()' and `GC_register_my_thread ()'. However, it appears that the main thread cannot be unregistered. What is the main thread supposed to do when it enters, say, a blocking system call and may not be able to cooperate for GC for a while? Thanks, Ludovic.

Begginer, Windows, c++

Daniel C — 2008-09-15T18:05:26

Hello, I am very exited about this GC, so far (what I have red) it looks goods and have good support. I am planning to use it in several proyect with several requeriments so this are my questiosn: 1)Is there some kind of benchmark about difference in performance with no using it. I know it is gonna loss som performance, but I would like to know how. 2)I have made some simple test: ______________________ int main(){ GC_INIT(); unsigned long i = 0; while (1){ i++; //comment char* aChar = new char[1024]; // GC_gcollect(); } return 0; } _______________________________ Should'n this work ok? I am having a total memory leak. If I set the GC_gcollet(); (uncommented) then it gets better but memory anyway increase (a low rate, but increase). Thanks in advance. ____________________________________________________________________________________ ¡Buscá desde tu celular! Yahoo! oneSEARCH ahora está en Claro http://ar.mobile.yahoo.com/onesearch

Begginer, Windows, c++

Daniel C — 2008-09-15T15:52:54

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

`USE_COMPILER_TLS' on GNU/Linux

Ludovic Courtès — 2008-09-14T20:48:23

Hi, Is there a reason why `USE_COMPILER_TLS' doesn't get defined on GNU/Linux platforms with GC 7.1? Strangely, `configure.ac' only defines it for GNU/kFreeBSD. Thanks, Ludovic.

I/O issues

Nicolas Cannasse — 2008-09-08T09:40:41

Hello, Sorry for the multiple messages recently, we could fix a lot of things thanks to the help of the people on the list. We are still experiencing one last issue, which is related to I/O functions. In some rare cases, two of our threads get blocked in a I/O function (either recv() , fread() , or __read_nocancel()). The two threads are usually unrelated - one can be a MYSQL response beeing read while the other is reading a file - but they get blocked at the same time. Seems like a deadlock to me. I wonder is there are some issues with multithreading + linux IO + gc signals. Even if the EINTR return values would not be handled everywhere, I guess it should still cause an error and not cause the threads to block. Any advice would be appreciated. Best, Nicolas

setjmp/longjmp and pthreads

Nicolas Cannasse — 2008-09-03T14:58:47

Hello, We have a multithreaded application server that use the Boehm GC and the NekoVM, but we are still experiencing some strange things. Neko is using setjmp/longjmp for exceptions handling. Is there any possibility that it might cause some trouble, for instance if a thread is interrupted by a GC signal during a longjmp ? Best, Nicolas

[announce] GC documentation in Texinfo format

Marco Maggi — 2008-08-29T19:11:50

A new version of GC documentation in Texinfo format is available: Details for Fri Aug 29, 2008 ---------------------------- * Changed the license to an adapted version of the GC license: the words "program" and "code" have been substituted with "document". * Moved all the copyright notices in the "< at >copying" environment so that the "< at >insertcopying" directive is used to include the material in the text. * Added the detailed node listing to the master menu.

[announce] GC documentation in Texinfo format

Marco Maggi — 2008-08-27T09:54:31

Due to personal learning problems I have converted some available GC documentation into Texinfo format. It is far from being a good documentation file. * not all the text has been corrected to use "we" to refer to the readers of the document, rather than to the authors of GC; * parts of the API defined in header files different from "gc.h" are not documented; * things that were confused in the original documentation are still confused in this document; * there are errors here and there. HB can you validate the copyright notices and tell me if it is a problem for you that I am is distributing this under the GNU Free Documentation License? I have added a line of copyright for me as part of making clear that this is unofficial documentation. Everything can be changed on your request. I hope that the file can be used as a trampoline to distribute better GC documentation.

[beginner] triggering collection of an object

Marco Maggi — 2008-08-26T06:30:43

Ciao, is there a way to force collection upon an object? I want to do it in a test program only to see how GC behaves and to verify if I am correctly using the interface. TIA

small bugs

Marco Maggi — 2008-08-26T06:07:51

Ciao, I am using GC 7.1 released tarball. * In "gc.h" the definitions: | # define GC_PRE_INCR3(x, n, type_of_result) \ | ((type_of_result)GC_pre_incr(&(x), (n)*sizeof(*x)) | # define GC_POST_INCR2(x, type_of_result) \ | ((type_of_result)GC_post_incr(&(x), sizeof(*x)) lack the ending ")". * In "gc.h" the definitions: | #ifdef GC_DEBUG | # define GC_POST_INCR2(x, type_of_result) \ | ((type_of_result)GC_post_incr(&(x), sizeof(*x))) | # ifdef __GNUC__ | # define GC_POST_INCR(x, n) \ | GC_POST_INCR3(x, typeof(x)) | # endif | #else/* !GC_DEBUG */ | # define GC_POST_INCR2(x, n, type_of_result) ((x)++) | # define GC_POST_INCR(x, n) ((x)++) | #endif are not correct: both GC_POST_INCR2 and GC_POST_INCR3 are mentioned; GC_POST_INCR makes no use of "n". I would do: | #ifdef GC_DEBUG | # define GC_POST_INCR3(x, n, type_of_result) \ | ((type_of_result)GC_post_incr(&(x), (n)*sizeof(*x))) | # ifdef __GNUC__ | # define GC_POST_INCR(x, n) \ | GC_POST_INCR3(x, n, typeof(x)) | # endif | #else/* !GC_DEBUG */ | # define GC_POST_INCR3(x, n, type_of_result) \ | ((x) += (n), (x) - (n)) | # define GC_POST_INCR(x, n) ((x) += (n), (x) - (n)) | #endif By the way, IMHO "type_of_result" should be used even when "GC_DEBUG" is undefined. * In "gc.h": | void * GC_malloc_many(size_t lb); and some other functions are missing a GC_API qualifier, does this mean that they are not for public use? * The tutorial on the web mentions a "gc_local_alloc.h" header file that I do not see in GC 7.1 (I only see a "include/private/thread_local_alloc.h"). * The tutorial on the web mentions a "--enable-full_debug" configuration option, but I see only "--enable-gc-debug" in the output of "configure --help".