Thread Locals (was Re: State of Loom)

[Andrew Haley]

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.

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