Ian Rogers writes:
> Jeroen Frijters wrote:
> > Ian Rogers wrote:
> >
> >> the attached patch modifies ThreadLocal to use an array of Objects hung
> >> off Thread rather than a weak hash map hung off Thread. On DaCapo's
> >> Jython benchmark this can improve the performance of the Jikes RVM by
> >> more than 10%. It also improves other DaCapo benchmark performance. GCJ
> >> already has a similar mechanism to use pthread thread locals.
> >>
> >
> > This patch looks wrong to me:
> >
> > 1) Values are strongly reachable, which means they potentially won't be
> > garbage collected.
> > 2) Value slots are reused without clearing them, which means potential
> > security hole.
>
> you're of course right. Without reinventing extra indirections in the
> locals it strikes me that the easiest way to solve these problems is
> with a finalizer (groan) in the thread local that iterates over every
> thread reverting the slot location to the sentinel value. I'll test and
> revise the patch.
In the gcj pthreads version I keep the WeakIdentityHashMap but I have
a look-aside cache that's used by get(). set() is slow by get() is
fast. Like this:
java::lang::ThreadLocal::get (void)
{
if (TLSPointer == NULL)
return internalGet (); // Slow version, creates the ThreadLocal and
updates the HashMap
tls_t* tls = (tls_t*)TLSPointer;
void *obj = pthread_getspecific(tls->key); // A fast lookup in an area of
memory the garbage collector doesn't scan.
if (obj)
return (::java::lang::Object *)obj;
::java::lang::Object *value = internalGet (); // Slow version again.
Garbage collection isn't affected because the use of the HashMap is
exactly the same as in the previous Classpath version, and the gc
doesn't scan the pthreads memory area used for thread locals. This
gets the fast path (the usual case) down to a few instructions. I
suppose it's only really an advantage on VMs with very low overhead
native calls.
Andrew.
