Thread local allocation

Tue Feb 12 22:05:00 GMT 2002

Boehm, Hans wrote:
>There are two reasons it isn't enabled for *-*-linux*:
>>1) I can only test X86 and Itanium.
>>2) Some of the code, particularly in specific.c, assumes an Itanium-like or
>stronger memory model. In particular, if you look at the code for
>setspecific(), it would need a memory barrier on Alpha, as would the
>corresponding inlined getspecific routine.
>
Right. It seems to me that the inlined getspecific (in specific.h) would 
not need any barrier because it does not do any writes? So how about a 
GC_memory_write_barrier() before:
 *(volatile tse **)(key -> hash + hash_val) = entry;
in setspecific, and:
 *cache_ptr = entry;
in slow_getspecific? I'm not sure about remove_specific.
>I would vote for turning this on on a case-by-case basis, after some
>(multiprocessor!) testing. I would guess that for a SPARC running in TSO
>mode, it's safe to turn it on as it is. The same is probably true for MIPS.
>For Alpha, it may be safe to turn on if you define USE_PTHREAD_SPECIFIC, so
>that it uses the official pthread-defined thread local storage primitives
>instead of my (faster on X86) hack. Or you would have to add the memory
>barriers. I don't claim to know anything about the PowerPC memory model,
>but I suspect that if it works for Alpha, it probably works on PowerPC, too.
>
Hmm. I can't easily test MP PowerPC or Alpha, but I'd like to turn it on 
anyway in order to get the performance increase. Perhaps we could leave 
it disabled (USE_PTHREAD_SPECIFIC) for alpha since it seems like that 
would be the most problematic one.
I might do a test with and without USE_PTHREAD_SPECIFIC to make sure 
that all this is worthwhile, but I suspect it will be on PowerPC. The 
linuxthreads implementation of pthread_self() on PPC looks far far worse 
than x86.
regards
Bryce.