RFR: 8003246: Add Supplier to ThreadLocal

[Doug Lea]

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