Thread Locals (was Re: State of Loom)

Andrew Haley aph at redhat.com
Sun May 31 10:06:39 UTC 2020


On 30/05/2020 11:53, forax at univ-mlv.fr wrote:
> ----- 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 -----
>>
>>> 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.

OK, I get that.

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

Sure, but that's a detail of how schedulers work rather than something
that should be exposed to application code.

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

That's what I meant by "awful". :-)

It's reasonable enough if you want to provide performance hints, but
if an application depends on pinning a virtual thread to a specific
carrier thread for correctness, the whole program becomes rather
fragile and difficult to maintain. It also breaks abstractions:
library code that relies on such a model would have to depend on
applications to use schedulers that do this.

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



More information about the loom-dev mailing list