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

[Thomas Stuefe]

On Fri, 11 Mar 2022 10:44:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > On 3/11/22 10:12, Thomas Stuefe wrote: We could also redefine SafeFetch on MacOS/AArch64 to not need WX. We could do this by statically generating SafeFetch on that platform, and it wouldn't be in the JIT region at all. Why not just do that? Do you mean using inline assembly?
> > I'd use out-of-line assembly, as I do for atomic compare-and-swap on linux: https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S But I guess inline would work.
> 
> Oh, this is neat. It would work on all platforms too, or on all we care to implement it for. And it would nicely solve the initialization window problem since it would work before stub routines are generated. We could throw `CanUseSafeFetch` away.
> 
> It seems we already do static assembly on bsd aarch. So there is already a path to follow.
> 
> But this could also be done as a follow up enhancement. I still like the OS TLS variable idea.

I spent some time doing a static implementation of SafeFetch on Linux x64, and its not super trivial. The problem is that we need to know addresses of instructions inside that function. I can set labels in assembly, and I can export them, but so far I have been unable to use them as addresses in C++ code. I will research some more.

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

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