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

[Johannes Bechberger]

On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Regarding the names of the new methods: Most of the usages for ThreadWXEnable use it to set the WXMode to WXWrite. The suggested names are therefore a bit misleading (when used in this context).

One could add another two methods:


class os {
...
// Platform does whatever needed to prepare for execution of generated code inside the current thread
os::pre_current_thread_jit_code_gen() NOT_MACOS_AARCH64({})
// Platform does whatever needed to clean up after executing generated code inside the current thread
os::post_current_thread_jit_code_gen() NOT_MACOS_AARCH64({})


But one would still have the problem of nesting (e.g. when code generating code calls code generating code).

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

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