This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Thread local allocation
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: java at gcc dot gnu dot org
- Date: Wed, 13 Feb 2002 15:51:36 +1300
- Subject: Re: Thread local allocation
- References: <40700B4C02ABD5119F000090278766443BEFAC@hplex1.hpl.hp.com>
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.