RFR: 8003246: Add Supplier to ThreadLocal

[Vitaly Davidovich]

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.

Thanks

Sent from my phone
On Dec 6, 2012 6:33 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

> On 12/06/12 03:23, Remi Forax wrote:
>
>> On 12/06/2012 06:10 AM, David Holmes wrote:
>>
>>> On 6/12/2012 5:39 AM, Akhil Arora wrote:
>>>
>>>> This patch adds a constructor to ThreadLocal to supply initial values
>>>> using the new Supplier functional interface. Please review. This work
>>>> was
>>>> done by Jim Gish.
>>>>
>>>> http://cr.openjdk.java.net/~**akhil/8003246.0/webrev/<http://cr.openjdk.java.net/~akhil/8003246.0/webrev/>
>>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8003246<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246>
>>>>
>>> ...
>>>
>>
>> There are two good reasons to provide a new ThreadLocal<>(() ->
>> initialValue), if all goes as planned, every Supplier will share the same
>> class so instead of having one class by thread local that want to specify
>> an
>> initialValue, we will have only 2 classes (or 3 if the ThreadLocal that
>> takes
>> a Supplier is a subclass) in memory.
>>
>
>
> These seem like really good reasons to implement as you
> suggested in last post, with a static factory that uses a non-public
> *final* subclass that wires initialValue to supplier call,
> and not otherwise modifying the ThreadLocal class.
> It has the added benefit of, by not touching ThreadLocal,
> guaranteeing that it is time/space-neutral for other existing
> uses. Which also means that any future time/space improvements
> in ThreadLocal will not need to be constrained by this change.
>
> Jim/Akhil, could you please redo it this way?
>
>
>  Also, letting people to subclass ThreadLocal is not a good idea because
>> if in
>> one location someone decide to override get() to by example add a logging
>> code (I've seen a similar problem) then suddenly all the codes that use
>> ThreadLocal.get() will not be able to inline it.
>>
>
> (Yes. We see this when our (very heavy) uses of ThreadLocal
> inside j.u.c. go from fast to slow mode due to overrides in other
> unrelated ThreadLocal classes in application code. I've many
> times considered introducing a "JDK-internal" variant of
> ThreadLocal to protect against such things. Possibly even
> one with only a finite fixed capacity, that would allow
> further speed ups. Or maybe just introducing say a dozen
> extra dedicated fields in class Thread, making it optimally fast
> at the expense of non-extensibility.)
>
> -Doug
>
>
>