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>
> Cc: "Mike Rettig" <mike.rettig at gmail.com>, "loom-dev" <loom-dev at openjdk.java.net>, "Douglas Surber"
> <douglas.surber at oracle.com>
> Envoyé: Jeudi 28 Mai 2020 12:59:50
> Objet: Re: Thread Locals (was Re: State of Loom)

> On 28/05/2020 10:27, forax at univ-mlv.fr wrote:
>> ----- 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.
> 
> Sure, that much is clear. We need a way to cache resources, and we
> need to do that in a way that is secure.
> 
>> 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.
> 
> Which is awful, frankly.

I should not have used the word "pin", because what is required is just to re-schedule the virtual thread on the same carrier thread, so it's less awful. 
In fact, it should be the default strategy if all cores are busy otherwise when a virtual threads migrate from a core to another, everything in the L2 cache need to be reloaded, causing a lot of cache misses just after the virtual thread is mounted to the carrier thread.

So having a way to dynamocally tag a virtual thread so it stay on the same carrier thread may be another solution, at the cost of having less parallelism.

> 
> Maybe what we really need is a nice way to create caches, but perhaps
> any attempt at a general-purpose cache would be {mis}used just as much
> as ThreadLocals are. Different applications have different lifetime
> requirements for their cached objects, so need different cache
> behaviour.
> 
> --
> 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

Rémi