Thread Locals (was Re: State of Loom)

[Alex Otenko]

If the objects are too big to be duplicated per Virtual Thread, then the
issue is not with ThreadLocal.

That is, even if you solved the problem with how to cache per Virtual
Thread, you still will have as many instances of Thingy as there are
Virtual Threads, ergo they still get duplicated too much.

Having realized this, you need to limit the number of Virtual Threads that
might be using Thingies. Then is the problem with ThreadLocal still there?

Alex

On Thu, 28 May 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.
>
> 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
>