RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

[Anton Kozlov]

On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.
>
> Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
> class ThreadInVMfromNative : public ThreadStateTransition {
>   ResetNoHandleMark __rnhm;
> 
> We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.

Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this.

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

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