[gclist] Boehm's GC and multi-threaded libraries

[Hans Boehm]

On Jan 22, 11:40am, Dean Brettle wrote:
> Subject: Re: [gclist] Boehm's GC and multi-threaded libraries

> Assuming:
>
> 1. for each call to the library, the threads created do not outlive the
> call (i.e. there is only one thread when the call completes).  For
> ImageVision, I _think_ this is the case for all but the methods
> beginning with q.
>
> 2. the GC is not called within the library (because I haven't done a
> REDIRECT_MALLOC)
>
> Why would there be a problem with passing pointers to GC'd memory into
> the library, even if the library expects the data to outlive the call?
> What is it about multi-threading that makes this a problem?  Or, is the
> problem due to the fact that we want to do _incremental_ GC?
>
>-- End of excerpt from Dean Brettle

I don't think I was very clear in my message.  The problem isn't directly
related to either threads or incremental GC.  The problem is just that you'll
be
mixing garbage-colllected allocation with the system malloc.  The "official"
interface to the collector specifies that garbage collected memory referenced
only from malloc objects may not be retained, since malloc'ed objects may not
be
scanned by the collector.  Thus if you pass the only reference to an object to
the library, and it saves a single reference to it in an object it malloc's,
you're in trouble, threas or not.  Fortunately, this rarely happens with C
libraries, since the generally have to be prepared to receive pointers to stack
objects.

In fact, things are a bit more complicated, since it's sometimes hard for the
collector to disregard the system malloc heap entirely.  On several platforms
(e.g. Irix and win32) it finds data areas associated with dynamic libraries by
enumerating the mappings in the address space and registering R/W mappings that
it can't otherwise explain as roots.  This may end up including at least some
of the malloc heap.  That's not really a correctness issue, but it can be a
serious performance issue for programs that allocate a lot of space through
both GC_malloc and the system malloc.  (At least in the Irix case, there may
actually be a better way to find the roots.  But 4.11 does it this way.)

Normally I would recommend avoid heavy use of the system malloc by using
GC_malloc_uncollectable and friends.  But the threads issues make that harder.

Hans


-- 
Hans-Juergen Boehm
boehm@mti.sgi.com