RFR: JDK-8283326: Implement SafeFetch statically

[David Holmes]

On Mon, 11 Apr 2022 11:57:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> `pthread_getspecific` and `pthread_setspecific` cannot be called from a signal handler, either. In particular, `pthread_setspecific` may call `malloc`.
>> 
>> On GNU/Linux, if you use initial-exec TLS, it is fully async-signal-safe. Less so for the other variants. But maybe this does not matter because the assembler implementation uses `os::Posix::ucontext_set_pc` to redirect the execution in a more direction fashion?
>
> @fweimer-rh I'll move `pthread_setspecific` out of signal handling, thanks for the hint.
> 
> `pthread_getspecific` may not be signal safe, but it has been in use in JVM signal handlers for decades (signal handlers call `Thread::current`, which uses TLS) and it works in practice on all Posix platforms.

Sorry I missed the use of pthread_setspecific in the signal handler - yes that is also unsafe. As noted pthread_getspecific is not listed to be safe but appears so in practice. It was investigated when we introduced the use of compiler-based thread-locals.

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

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