On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore <[email protected]> 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
