On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov <akoz...@openjdk.org> 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

Reply via email to