RFR: 8003246: Add Supplier to ThreadLocal

[Remi Forax]

On 12/06/2012 08:01 PM, Peter Levart wrote:
> 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.

No, there is no way to have such guarantee, here, it works either 
because the only class ThreadLocal you load is FastThreadLocal or 
because the VM has profiled the callsite see that you only use 
FastThreadLocal for a specific instruction.

>
>
> Regards, Peter

cheers,
Rémi

>
> 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
>>
>>
>>
>>
>