[Gc] Attaching and dettaching existing threads

Thong (Tum) Nguyen tum@veridicus.com
Tue, 14 Oct 2003 08:24:00 +1300


Hi :D,

> -----Original Message-----
> From: gc-admin@napali.hpl.hp.com [mailto:gc-admin@napali.hpl.hp.com] On
> Behalf Of Boehm, Hans
> Sent: Tuesday, 14 October 2003 7:17 a.m.
> To: 'Thong (Tum) Nguyen'; gc@napali.hpl.hp.com
> Subject: RE: [Gc] Attaching and dettaching existing threads
> 
> I agree that this needs to be reconsidered, though not for 6.3.
> 
> The original model was that notifying the GC of a new thread should be as
> transparent as possible.  On win32 with the GC as a separate dynamic
> library,
> it's completely transparent at the moment; all new threads are
> automatically
> attached.  In all other cases we try to intercept all thread creations,
> usually
> with macros include from gc.h.  The intent is that if you define
> GC_THREADS
> and include "gc.h" everywhere, the rest should be automatic on all
> platforms.
> 

True, I forgot about how the win32 DLL system allowed interception of all
thread creations.  Portable.net on windows at the moment statically links
with libgc and we call upon the wrapped thread methods.  It appears very
stable and is more convenient (we always know when a thread is about to use
any GC-heap object).  All the methods I've used to try building the DLL
using free tools produced crash prone DLLs.  Maybe I just didn't try hard
enough ;-).

> My feeling is that for C/C++ clients, this is usually the right model.
> But
> its weaknesses are:
> 
> 1) It's hard to exclude a thread.  You might rarely want to do that to
> avoid stopping
> it during GC.  But this imposes severe constraints on what that thread can
> do.
> In particular, it can't write any pointers to the collected heap, or
> allocate
> memory using the GC_ routines.
> 
> 2) The current macro-based interception mechanism doesn't actually
> guarantee that
> we intercept all thread creations.  The code that spawns the thread may
> not be
> recompilable.  It's occasionally useful to "attach" the resulting thread
> after the
> fact.  On Linux, this is probably fixable with linker-based interception,
> at least for
> dynamic executables.  I don't know how to fix it for Windows.
> 
> 3) This model doesn't handle threads that were running before the dynamic
> library
> containing the GC was loaded.  (Actually, I suspect it does in the win32
> GC-as-DLL case,
> since I would expect the library to be notified of all such threads.  But
> it works
> nowhere else.)
> 
> I think my preference would be to stick with the current model of
> transparently
> attaching threads, but to add two more public calls similar to what Tum
> proposed:
> 
> 1) GC_watch_thread() - makes sure that the current thread is known to the
> GC, even if
> it was created in a way that couldn't be intercepted.  It
> would take a bit of work to ensure that this is a no-op if the thread was
> already known
> to the GC, but I think that's necessary.
> 
> 2) GC_ignore_thread() - Ensures that the current thread is not known to
> the GC.
> Should be called just before exit by threads that called
> GC_watch_thread(), or
> by threads that may have been automatically watched but don't want to be
> stopped
> during GC.  No-op if it was already unknown.
> 
> (I decided during the last win32_threads.c revision that the attach/detach
> terminology is not my preferred choice, since it conflicts with the
> pthreads use
> of "detach".)
> 
> This diverges from the JNI/.NET model, in that threads are "watched" by
> default
> if you recompile suitably.  But I don't think that's a serious problem,
> and for
> C/C++ clients it makes life a bit easier, and we remain compatible with
> current
> versions.
> 
> Does this sound right?
> 

That's exactly what we're after!  If you need any volunteers to add these
methods to linux & windows you know who to call ;).

All the very best,

^Tum