On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore <cole...@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