[Gc] FYI for GC users on multi-threaded apps

Boehm, Hans hans.boehm at hp.com
Thu Jun 10 17:29:44 PDT 2010

I don't think thread-local allocation should be an issue.

I think there are some platform-specific issues with the GC properly tracing through pointers stored in thread-local variables.  If you need to use thread-local data to hold pointers to the garbage-collected heap, it's much safer to also store a copy of the pointer someplace else, where the collector can find it more easily.  The problem is that most operating systems don't provide a good way for the collector to enumerate thread-local data.

The thread-local data used by the collector itself should be fine, since the collector knows where that is.


> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com 
> [mailto:gc-bounces at linux.hpl.hp.com] On Behalf Of Tracy Brown
> Sent: Tuesday, June 08, 2010 9:51 PM
> To: Ivan Maidanski
> Cc: gc at linux.hpl.hp.com
> Subject: RE: [Gc] FYI for GC users on multi-threaded apps
> Honestly, I had only experimented with enabling posix threads 
> on the configure script. It was an interesting exercise for 
> me since what I had implemented was very experimental and the 
> resulting architecture change had no peformance impact - if 
> anything it helped.
> Actually the thread specific data stuff was a generalization. 
> What I had been doing was very odd and experimental and in a 
> perfect world, should have worked. I looked at the source for 
> GC and couldn't easily figure on a proper reason for my 
> particular issue. I have a hunch it's TSD related but the way 
> GC operates, it aborts when debug is enabled before the 
> application would normally experience failure. I just figured 
> you guys are really good and have code to deduce a sequence 
> of evens leading into such as TSD style failure.
> And really, I have no idea if I'm close to correct. I'm just 
> grateful to have such a facility available to the public.
> Cheers,
> Tracy.
> ________________________________________
> From: Ivan Maidanski [ivmai at mail.ru]
> Sent: Tuesday, June 08, 2010 9:02 PM
> To: Tracy Brown
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] FYI for GC users on multi-threaded apps
> Hi!
> As for BDWGC, thread-local memory is used only if -D 
> Tue, 8 Jun 2010 12:55:09 -0700 Tracy Brown <tbrown at perfnet.com>:
> >
> > I've been debugging a daemon where I had implemented GC and 
> discovered (though obvious now that I know) that you cannot 
> use GC in a multi-threaded environment where you dispatch to 
> another thread and that other thread returns a result that is 
> allocated dynamically. There may be application specific 
> reasons as to why this is the case for me but the short 
> answer is that GC uses thread specific memory that isn't 
> accessible to another thread. If there's any vestige of truth 
> to this, maybe someone can elaborate and make a note in the 
> usage docs. As for me, I altered my dispatching architecture 
> to retain GC. Hope this helps someone somewhere avoid a little grief.
> >
> > Cheers,
> >
> > Tracy Steven Brown
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list