Thread Locals (was Re: State of Loom)

[Remi Forax]

We have our own Thingy in the JDK too,
by example, StringCoding which is used to convert String to byte and vice versa, it relies on two thread locals [1], one for the encoder and one for the decoder.

I believe we need a way to say if a ThreadLocal means virtual thread locals or carrier thread local.

regards,
Rémi

[1] https://github.com/openjdk/loom/blob/fibers/src/java.base/share/classes/java/lang/StringCoding.java#L66

----- Mail original -----
> De: "Douglas Surber" <douglas.surber at oracle.com>
> À: "Andrew Haley" <aph at redhat.com>
> Cc: "loom-dev" <loom-dev at openjdk.java.net>
> Envoyé: Mercredi 27 Mai 2020 19:08:19
> Objet: Re: Thread Locals (was Re: State of Loom)

> Most of this code was written many, many years ago. We demonstrated that holding
> a Thingy in a static field resulted in excessive contention on the Thingy.
> Rather than invent a new data structure that we would have to maintain, we
> chose to leverage the tool that the Java class library provided, ie
> ThreadLocal. Could we do something different? Certainly. But having to roll our
> own increases our (already excessive) maintenance burden. I'd much rather use
> standard tools when possible, and in my use case ThreadLocal is acceptable. For
> now.
> 
> If the need arose to eliminate the ThreadLocals we would attempt to make the
> Thingys non-blocking. The benefit of that is eliminating the cost of having
> multiple Thingys. From experience making other parts of our code non-blocking I
> have reason to think that making these Thingys non-blocking would be
> challenging and would cause maintenance problems at least in the short term.
> These Thingys are stable so once we got all the bugs ironed out we'd be ok.
> Only if we couldn't make one or more non-blocking would be roll our own
> non-blocking Thingy sharing tool. Still, I'd much prefer to use a tool Java
> provides and I don't think I'm alone.
> 
> Douglas
> 
>> On May 27, 2020, at 9:16 AM, Andrew Haley <aph at redhat.com> wrote:
>> 
>> 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://urldefense.com/v3/__https://www.redhat.com__;!!GqivPVa7Brio!NPUffY9EmeqSPKmerY_5RK8hZVg0Snysse_h8QxZXEHqSwEDd-HfD2yUBheAR8vnC48$
>> >
>> https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!GqivPVa7Brio!NPUffY9EmeqSPKmerY_5RK8hZVg0Snysse_h8QxZXEHqSwEDd-HfD2yUBheAxF1XcaU$
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671