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

[Anton Kozlov]

On Thu, 10 Mar 2022 06:00:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Arguably we should restore, upon leaving the VM, the state that has been present before. Because a native thread may already have modified the wx state and overruling it is just rude. But I offhand don't see a way to do this since we have no way (?) to query the current state.

How in general safe to call SafeFetch on a native thread that has no Thread object? The JVM has not initialized the thread, so there could be no JVM signal handler installed. Or using libjsig is mandatory for this case?

I also don't know a good way to query the WX state.

> It also would be slightly faster. Using Thread, we'd access TLS to get Thread::current, then dereference that to read the wx state . OTOH using OS TLS, we access TLS to get the wx state directly. We save one dereference.

If we compare approaches in general (not only SafeFetch), the Thread is already in hands, so we should to compare a read of the field from a C++ object, and the read of a TLS variable. The former could not be slower than the latter.

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

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