Faster thread local statics

[EgorBo]

I noticed that various Thread Statics helpers constantly pop up in native traces in micro and macro benchmarks, e.g. Platform-JSON TE benchmark:

A simple demo:

while (true)
{
    var arr = ArrayPool<int>.Shared.Rent(10000);
    ArrayPool<int>.Shared.Return(arr);
}

when it spins it spends most of the time in JIT_GetSharedGCThreadStaticBaseDynamicClass:

where it just early outs:

if only we had a dedicated register (I think we can afford one at least on arm) which always pointed to current thread we could avoid that kind of overhead. Something like this (pseudocode):

if (!CTreg->tlsInited)
  initTls();
var field = CTreg->field;

making TLS access super cheap. As a bonus it might help with some pinvoke/safepoints routine?
Thoughts?
cc @jkotas

category:cq
theme:runtime
skill-level:intermediate
cost:small
impact:medium

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

I do not think it is a good idea to deviate from the standard ABI by having .NET-specific dedicated register that points to the thread-local block. It has ripple effects and comes with number of trade-offs. Some things will get faster, some things will get slower.

There is a dedicated register in the standard ABI that points to the thread-local block already: gs:[0] on Windows x64, etc. The JIT does not know how to inline this access today. If we wanted to improve things here, we should teach the JIT how to inline the gs:[xxx] statics access. It is basically same idea as what you have proposed, except that you replace the .NET specific dedicated register with the standard ABI one.

We can also work on reducing number of indirections to go from the thread-local register to the actual static. There is at least one indirection that can be avoided by refactoring how thread statics work.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I noticed that various Thread Statics helpers constantly pop up in native traces in micro and macro benchmarks, e.g. Platform-JSON TE benchmark:

A simple demo:

while (true)
{
    var arr = ArrayPool<int>.Shared.Rent(10000);
    ArrayPool<int>.Shared.Return(arr);
}

when it spins it spends most of the time in JIT_GetSharedGCThreadStaticBaseDynamicClass:

where it just early outs:

if only we had a dedicated register (I think we can afford one at least on arm) which always pointed to current thread we could avoid that kind of overhead. Something like this (pseudocode):

if (!CTreg->tlsInited)
  initTls();
var field = CTreg->field;

making TLS access super cheap. As a bonus it might help with some pinvoke/safepoints routine?
Thoughts?
cc @jkotas

Author:	EgorBo
Assignees:	-
Labels:	tenet-performance, area-CodeGen-coreclr, area-VM-coreclr, untriaged
Milestone:	-

[EgorBo]

@jkotas thanks for the feedback! I was about to ask "should I rename it to "make TLS faster?" 🙂
BTW, related: #63622