RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]

[Andrew Haley]

On Fri, 11 Mar 2022 12:18:36 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> > According to https://forums.swift.org/t/concurrencys-use-of-thread-local-variables/48654: "these accesses are just a move from a system register plus a load/store at a constant offset."
> 
> Ideally you'd still benchmark that. Some AArch64 implementations have really, really slow moves from the system register used as the thread pointer. Hopefully Apple's implementation isn't in that category.

In a tight loop, loads from __thread variables take 1ns. It's this:


    0x18ea1c530 <+0>:   ldr    x16, [x0, #0x8]
    0x18ea1c534 <+4>:   mrs    x17, TPIDRRO_EL0 
    0x18ea1c538 <+8>:   and    x17, x17, #0xfffffffffffffff8
    0x18ea1c53c <+12>:  ldr    x17, [x17, x16, lsl #3]
    0x18ea1c540 <+16>:  cbz    x17, 0x18ea1c550          ; only executed first time
    0x18ea1c544 <+20>:  ldr    x16, [x0, #0x10]
    0x18ea1c548 <+24>:  add    x0, x17, x16
    0x18ea1c54c <+28>:  ret    


... which looks the same as what glibc does. Not bad, but quite a lot more to do than a simple load.

I'd still use a static SafeFetch, with no W^X fiddling. It just seems to me much more reasonable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7727