Thread Locals (was Re: State of Loom)

[Alan Bateman]

On 27/05/2020 16:03, Douglas Surber wrote:
> 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.
Part 2 lists topics, beyond virtual threads, that are still being 
explored. Scope variables are an alternative to using TLs when you want 
to make context available to some transitive callee on the stack. There 
is a section on Processor locals that I think is close to what you are 
looking for. There was been some early exploration in that area and 
there is a branch in the repo with a primitive based on the the Linux 
Restartable Sequences mechanism - it might be a bit of date but it 
demonstrates what is possible.

You are right that virtual threads creating TLs creates may lead to 
unbounded memory usage and/or performance issues. The current prototype 
allows virtual threads to be created that don't support TLs but this is 
problematic when trying to run a lot of existing code.  Many of usages 
of TLs in the JDK have been replaced in the Loom repo so that they 
aren't contributing to the problem.

-Alan.