On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov <[email protected]> wrote:
>> 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.
I've dropped this transition here and in similar places after state tracking
always available. As a benefit, there are few places really using the setter
and all of them are tied to VM_ENTRY macro or similar one. I expect we don't
need to do W^X management near every java thread state change.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2200
