[Gc] RE: Registering TLS as roots

Ben Hutchings ben.hutchings at businesswebsoftware.com
Wed Oct 20 04:08:36 PDT 2004


I wrote:
> Normally thread-local storage (TLS) aka thread-specific storage (TSS)
> is not treated as part of the root set.  However I don't see any
> general way to store copies of pointers in TLS in places that are in
> the root set.

I'll expand on this: I'm aware of the advice to keep such pointers in
the stack somewhere.  However, there's no guarantee that merely storing
a pointer in an automatic variable actually keeps it in the stack.  We
have a function that stores a pointer in TLS and in an automatic
variable, and G++ 3.4 optimises away storage of the automatic variable
because it is not used after being written to TLS.  So the object it
pointed to was collected, causing our program to crash.

> I know how to find TLS on Windows NT on x86 (it's in the TEB structure
> defined in <winternl.h> and that can be found through fs:[18h]) and I
> can probably look up details of other TLS implementations but this
> sort of platform-specific hackery doesn't seem like the best solution.
> 
> Does anybody have any suggestions for how to include TLS in the root
> set or how to keep extra copies of such pointers elsewhere (and only
> so long as they are also in TLS)?

The solution I came up with was to add a TLS interface to the GC as an
alternative to the native TLS interfaces.  It's a cross between the
Win32 and pthreads interfaces:

  typedef int GC_thread_key;
  typedef void (* GC_thread_specific_cleanup)(void *);
  GC_API int /* GC_bool */ GC_thread_key_create(GC_thread_key *,
	
GC_thread_specific_cleanup);
  GC_API void GC_thread_key_delete(GC_thread_key);
  GC_API void * GC_thread_getspecific(GC_thread_key);
  GC_API void GC_thread_setspecific(GC_thread_key, void *);

So far I have only implemented this in linux_threads.c.  Since every
GC_Thread_Rep is reachable, I added an array of user TLS pointers to
that.  (Does this depend on ALL_INTERIOR_POINTERS?  Should I fix
that?)  I can probably implement this within some of the other thread
support implementations in time.

Is anyone interested in this?

Would it be better to wrap the native TLS interface instead, like we
wrap many other calls?


More information about the Gc mailing list