Thread Locals (was Re: State of Loom)

[Douglas Surber]

I use ThreadLocals in two ways. 1) other parts of the system create a ThreadLocal to effectively pass a parameter value up the stack outside of the method call mechanism and 2) I create a ThreadLocal to hold a shared resource and still avoid contention. The first use isn't that important to me. The second is a big deal. 

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.

Theoretically I only need one (of each) resource per hardware thread. Having a resource per Thread in current Java is wasteful, but works. In practice only a limited number of the total system threads ever call my code so many fewer resources are created than the total number of Threads. 

A resource per VirtualThread sounds like a problem. The entire point of VirtualThreads is that they are cheap; there's no reason not to create as many as you want. If  a ThreadLocal is tied to a VirtualThread and there are many of them, then my code will create many expensive resources. Likely, many or even most/all of those resources will only be used a small number of times, possibly just once. This will cause my code to be unusable.

Ideally I'd like to have a CpuLocal. That is a ThreadLocal that is per core (per hardware thread). If that's not feasible then a ThreadLocal that is per carrier Thread should get me back to where I am today, more or less. 

I can guarantee that the VirtualThread will not be suspended during a call to a resource. I don't care if a single call to my code accesses more than one instance of any resource.

Maybe my use case is only a small fraction of the uses of ThreadLocals but my intuition is that it is actually a common use case.

Douglas

> On May 26, 2020, at 5:55 PM, loom-dev-request at openjdk.java.net wrote:
> 
> Message: 3
> Date: Tue, 26 May 2020 14:21:29 +0100
> From: Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>
> To: loom-dev at openjdk.java.net <mailto:loom-dev at openjdk.java.net>, Magnus Ihse Bursie
> 	<magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
> Subject: Re: State of Loom
> Message-ID: <5988883a-0b3f-aa71-96e6-a9e2d677e30b at oracle.com <mailto:5988883a-0b3f-aa71-96e6-a9e2d677e30b at oracle.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 26/05/2020 13:16, Ron Pressler wrote:
>> I meant the former, ?obvious? reading. Because there are many more threads,
>> the footprint impact of thread-local data is bigger.
>> 
> Also just to add to Ron's comment is that there is ongoing effort to 
> reduce the use of TLs in the JDK. That will help with the footprint when 
> virtual threads are using standard APIs. It is also possible to create 
> virtual threads that don't support TLs. It would of course be nice for 
> that to be default but that makes it really hard to run a lot of 
> existing code.
> 
> -Alan
>