Thread Locals (was Re: State of Loom)

[Andrew Haley]

On 27/05/2020 16:03, Douglas Surber wrote:

> My code has multiple relatively expensive shared resources. Every
> call to my code potentially needs access to one or more of those
> shared resources for a brief moment. These resources are expensive
> to create and consume non-trivial heap space. Use of the resources
> is a simple call: call a method on the resource; get a
> response. Experience has shown that having one instance of each
> resource in a static field leads to unacceptable
> contention. Balancing cost of the resources with contention we keep
> the resources in ThreadLocals. Each user call can get use of a
> resources without contention while still limiting the total number
> of resources created.

Let's call your relatively expensive shared resource a Thingy, for
short.

ThreadLocals are not cheap: the last time I traced through it, there
were about 12 field loads and 5 conditional branches for a tl.get(),
best case. It can't be so hard to keep a global shared linked list of
Thingys and whenever you want one, remove it from the list with a
getAndSet() operation, and remember to put it back when you're
done. Is doing that really much more expensive than a
ThreadLocal.get() ? Or maybe the problem is that of lifetimes, in that
none of the existing code knows when it no longer needs its Thingy;
but that can't be true because you said that you only need them for a
brief moment.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671