RFR: 8003246: Add Supplier to ThreadLocal (original) (raw)

Doug Lea dl at cs.oswego.edu
Thu Dec 6 11:32:35 UTC 2012

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/viewbug.do?bugid=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

More information about the core-libs-dev mailing list