On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger <[email protected]>
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
