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

[Anton Kozlov]

On Thu, 10 Mar 2022 18:07:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > > Is it possible to change SafeFetch only? Switch to WXExec before calling the stub and switch WXWrite back unconditionally? We won't need to provide assert in ThreadWXEnable. But SafeFetch can check the assumption with assert via Thread, if it exists.
> > > 
> > > 
> > > But SafeFetch could be used from outside code as well as VM code. In case of the latter, prior state can either be WXWrite or WXExec. It needs to restore the prior state after the call.
> > 
> > 
> > I'm not sure I understand what is the "outside code". The SafeFetch is the private hotspot function, it cannot be linked with non-JVM code, isn't it?
> 
> Sorry for being imprecise. I meant SafeFetch is triggered from within a signal handler that runs on a foreign thread. E.g. AGCT or error handling.

Then the OS TLS way is not better since when the signal handler and SafeFetch start, the state is unknown and is only assumed to be Write (in initialization of TLS variable).

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

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