Thread Locals (was Re: State of Loom)

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Andrew Haley" <aph at redhat.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Mike Rettig" <mike.rettig at gmail.com>
> Cc: "loom-dev" <loom-dev at openjdk.java.net>, "Douglas Surber" <douglas.surber at oracle.com>
> Envoyé: Jeudi 28 Mai 2020 11:03:07
> Objet: Re: Thread Locals (was Re: State of Loom)

> On 27/05/2020 20:38, forax at univ-mlv.fr wrote:
> 
>> it's only safe to use a thread local bound to a carrier thread if
>> you are using it as a cache, like StringCoding does.
> 
> And the bound object is either immutable or non-preemptable. This all
> sounds much to hairy to me.
> 
> Are we reaching for "Let's bind a StringCoding to a carrier thread" as
> a proxy for "Let's make sure we don't create too many StringCodings" ?

We have mutable objects, like the charset encoder/decoder, the netty buffers, etc that are currently bound to real threads using thread local.
Those objects are too big to be duplicated to have one per virtual thread.
That's the issue that need to be solved.

Another solution is to bind those Thingy to a stack before the virtual threads are created, but it requires to pin the virtual threads to a peculiar carrier thread.

Rémi

> 
> --
> 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