RE: Roots observed in GC stack with threads

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of Lincoln Quirk
> Sent: Tuesday, November 27, 2007 1:22 PM
> To: skaller
> Cc: gc@...
> Subject: Re: [Gc] Roots observed in GC stack with threads
>
> On Wed, Nov 28, 2007 at 05:56:01AM +1100, skaller wrote:
> >
> > On Mon, 2007-11-26 at 21:48 -0500, Lincoln Quirk wrote:
> >
> > > The program is in a complex infinite loop which results
> in several
> > > allocations each iteration. The essence of it is that it's
> > > constructing a new node in a linked list on each
> iteration, but the
> > > head is being advanced as fast as the tail. I (fairly strongly)
> > > believe I'm updating any pointers to the old head, so
> that the old
> > > elements in the list should not be retained and the
> collector should
> > > properly collect it as execution continues.
> >
> > Be good if you could give the actual data structure? You don't say
> > whether your linked list is doubly or singly linked.
> >
> > If it is doubly linked you probably forgot to NULL out the end note
> > 'next' pointer, leaving the tail still reachable.
>

explicit thread registration

Hi,

We've been successfully using libgc in Inkscape for a while now, but
we're increasingly having issues with incompatibilities with libraries
with worker threads for callbacks, and with debugging tools like
valgrind[1].

All of the incompatibilities stem from the methods which libgc uses to
automatically establish the base address of the stack and find new
threads.  I think all that is required is an additional runtime "mode"
of libgc which turns off all of the automatic thread/stack registration
logic, and the addition of a call something like:

 GC_API void GC_register_thread GC_PROTO((GC_PTR));

The call would register the current thread with libgc (if it's not been
registered already), with the provided pointer being the base address to
use for the stack (typically the address of a local variable).  I think
the call should be idempotent except that an "earlier" base address will
replace a "later" one.

Threads could be automatically unregistered using the platform's
mechanism for destroying thread-local data on thread exit, though it
might make sense to also provide a GC_unregister_thread.

Now, one thing I'm concerned about how this should interact with
GC_INIT().  Would GC_INIT be universally safe to call without any
threads registered?  Are there any other difficulties with this idea?

-mental

how to get the gc allocated bytes?

I call GC_gcollect() and then I call GC_get_heap_size(), but the result 
is not 0. How can I know how many bytes are allocated by the collector?

Naming of debug version libraries

Wouldn't it be preferable to suffix the debug version library with 'd'? 
since it's pretty much an established principle nowadays for almost 
every library out there.

RE: how to get the gc allocated bytes?

Probably your best bet is to run a program that just calls GC_gcollect a couple of times with the
GC_PRINT_STATS or GC_PRINT_VERBOSE_STATS environment variable set.  For gc7, this will print the
amount of live memory found in the heap.  This might include some blacklisted pages as atomic reachable
memory, though probably not if you don't allocate anything.

In general, the collector allocates a few, usually small, data structures in its own heap.  I wouldn't
expect these to be terribly significant unless you have an almost empty heap, you have a very large number
of threads, or there are a high proportion of finalizable objects or "disappearing links".

The heap is grown in much larger, though initially not huge, increments.  And the collector explicitly
expands the heap to its initial size at startup.

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of Achilleas
> Margaritis
> Sent: Sunday, December 02, 2007 1:09 PM
> To: gc@...
> Subject: [Gc] how to get the gc allocated bytes?
>
> I call GC_gcollect() and then I call GC_get_heap_size(), but
> the result is not 0. How can I know how many bytes are
> allocated by the collector?
>
> _______________________________________________
> Gc mailing list
> Gc@...
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

RE: explicit thread registration

Have you looked at GC_register_my_thread and friends in gc7?  You still have to bypass the macro
definitions of thread creation primitives, which should probably be made easier.  But otherwise it
sounds to me like that's bascically what you want (except for the fact that it's not terribly well tested,
and the code for retrieving the thread stack base just returns GC_UNIMPLEMENTED on some platforms).

GC_INIT() should register the thread it's called from,which may have to be the main thread.

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of MenTaLguY
> Sent: Sunday, December 02, 2007 11:41 AM
> To: GC Mailing List
> Subject: [Gc] explicit thread registration
>
> Hi,
>
> We've been successfully using libgc in Inkscape for a while
> now, but we're increasingly having issues with
> incompatibilities with libraries with worker threads for
> callbacks, and with debugging tools like valgrind[1].
>
> All of the incompatibilities stem from the methods which
> libgc uses to automatically establish the base address of the
> stack and find new threads.  I think all that is required is
> an additional runtime "mode"
> of libgc which turns off all of the automatic thread/stack
> registration logic, and the addition of a call something like:
>

RE: Naming of debug version libraries

At least on Linux, I don't see much of a convention along these lines.  Do you have examples?  Where you
referring to a particular platform?

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of Achilleas
> Margaritis
> Sent: Monday, December 03, 2007 3:06 AM
> To: gc@...
> Subject: [Gc] Naming of debug version libraries
>
> Wouldn't it be preferable to suffix the debug version library
> with 'd'?
> since it's pretty much an established principle nowadays for
> almost every library out there.
>
> _______________________________________________
> Gc mailing list
> Gc@...
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>

Re: how to get the gc allocated bytes?

O/H Boehm, Hans έγραψε:
> Probably your best bet is to run a program that just calls GC_gcollect a couple of times with the
GC_PRINT_STATS or GC_PRINT_VERBOSE_STATS environment variable set.  For gc7, this will print the
amount of live memory found in the heap.  This might include some blacklisted pages as atomic reachable
memory, though probably not if you don't allocate anything.
> 
> In general, the collector allocates a few, usually small, data structures in its own heap.  I wouldn't
expect these to be terribly significant unless you have an almost empty heap, you have a very large number
of threads, or there are a high proportion of finalizable objects or "disappearing links".
> 
> The heap is grown in much larger, though initially not huge, increments.  And the collector explicitly
expands the heap to its initial size at startup.
> 
> Hans
> 
>> -----Original Message-----
>> From: gc-bounces@...
>> [mailto:gc-bounces@...] On Behalf Of Achilleas
>> Margaritis
>> Sent: Sunday, December 02, 2007 1:09 PM
>> To: gc@...
>> Subject: [Gc] how to get the gc allocated bytes?
>>
>> I call GC_gcollect() and then I call GC_get_heap_size(), but
>> the result is not 0. How can I know how many bytes are
>> allocated by the collector?
>>
>> _______________________________________________
>> Gc mailing list
>> Gc@...

Re: Naming of debug version libraries

O/H Boehm, Hans έγραψε:
> At least on Linux, I don't see much of a convention along these lines.  Do you have examples?  Where you
referring to a particular platform?
> 
> Hans
> 
>> -----Original Message-----
>> From: gc-bounces@...
>> [mailto:gc-bounces@...] On Behalf Of Achilleas
>> Margaritis
>> Sent: Monday, December 03, 2007 3:06 AM
>> To: gc@...
>> Subject: [Gc] Naming of debug version libraries
>>
>> Wouldn't it be preferable to suffix the debug version library
>> with 'd'?
>> since it's pretty much an established principle nowadays for
>> almost every library out there.
>>
>> _______________________________________________
>> Gc mailing list
>> Gc@...
>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>

To tell you the truth, my target platform is Windows (not because of 
preference, but because of contracts). Almost all debug versions of 
libraries these days, under Windows, come with a 'd' suffix at the end, 
making it easy to link them against the debug version of a program. Some 
examples: wxbase28d.lib (wx widgets), alld.lib (allegro (its simplicity 

[patch] darwin: clean up some code.

Hi all,

this patch cleans up a sin I did earlier.

Ok for trunk?
Tested on all darwin platforms except ppc64.

Thanks,
Andreas

2007-12-07  Andreas Tobler  <a.tobler@...>

	* dyn_load.c (GC_dyld_image_add): Remove ifdef clause and use the macro
	GC_GETSECTBYNAME instead.
	* include/private/gc_priv.h: Define GC_GETSECTBYNAME according to the
	architecture (Darwin).

Index: dyn_load.c
===================================================================
RCS file: /cvsroot/bdwgc/bdwgc/dyn_load.c,v
retrieving revision 1.13
diff -u -r1.13 dyn_load.c
--- dyn_load.c	4 Aug 2007 06:26:29 -0000	1.13
+++ dyn_load.c	7 Dec 2007 20:39:42 -0000
 <at>  <at>  -1064,13 +1064,8  <at>  <at> 
     const struct GC_MACH_SECTION *sec;
     if (GC_no_dls) return;
     for(i=0;i<sizeof(GC_dyld_sections)/sizeof(GC_dyld_sections[0]);i++) {
-#   if defined (__LP64__)