There's a quick trick that guarantees in-lining of get/set/remove:
public static class FastThreadLocal<T> extends ThreadLocal<T> {
@Override
public final T get() { return super.get(); }
@Override
public final void set(T value) { super.set(value); }
@Override
public final void remove() { super.remove(); }
}
....just use static type FastThreadLocal everywhere in code.
I tried it and it works.
Regards, Peter
On 12/06/2012 01:03 PM, Doug Lea wrote:
On 12/06/12 06:56, Vitaly Davidovich wrote:
Doug,
When you see the fast to slow ThreadLocal transition due to class
loading
invalidating inlined get(), do you not then see it get restored back
to fast
mode since the receiver type in your call sites is still the monomorphic
ThreadLocal (and not the unrelated subclasses)? Just trying to
understand what
Rémi and you are saying.
The possible outcomes are fairly non-deterministic, depending
on hotspot's mood about recompiles, tiered-compile interactions,
method size, Amddahl's law interactions, phase of moon, etc.
(In j.u.c, we have learned that our users appreciate things
being predictably fast enough rather than being
unpredictably sometimes even faster but often slower.
So when we see such cases, as with ThreadLocal, they get added
to todo list.)
-Doug
