RFR: 8266742: Check W^X state on possible safepoint [v2]

[David Holmes]

On Fri, 14 May 2021 18:13:14 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change option and method name
>
> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 67:
> 
>> 65: }
>> 66: 
>> 67: void SafepointMechanism::process_if_requested(JavaThread* thread) {
> 
> Looking at the stack from the crash:
> 
> 
> V [libjvm.dylib+0x8c1060] _ZN21MarkActivationClosure12do_code_blobEP8CodeBlob+0x3c 
> V [libjvm.dylib+0x8fea78] _ZN10JavaThread11nmethods_doEP15CodeBlobClosure+0x84 
> V [libjvm.dylib+0x401100] _ZN14HandshakeState18process_self_innerEv+0x18c 
> V [libjvm.dylib+0x400f60] _ZN14HandshakeState15process_by_selfEv+0x48 
> V [libjvm.dylib+0x832690] _ZN18SafepointMechanism25process_if_requested_slowEP10JavaThread+0x54 
> V [libjvm.dylib+0x8fe4b8] _ZN10JavaThread44check_safepoint_and_suspend_for_native_transEPS_+0x24 
> V [libjvm.dylib+0x92395c] _ZN19ProgrammableInvoker13invoke_nativeEPFvPhES0_P10JavaThread+0x118 
> V [libjvm.dylib+0x923aa8] PI_invokeNative+0x104 
> J 2565 jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(JJ)V jdk.incubator.foreign at 17-ea (0 bytes) @ 0x00000001189eeed0 
> 
> 
> why aren't we adding the assertion closer to the frame that crashed, where we need it, like for example:
> 
> `HandshakeState::process_self_inner()`

If we push the check too low we only do it when we hit this code and there is something to process, but we want to detect when we reach this code in the wrong state even if we wouldn't actually crash at this time due to there not being an active poll.

David

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

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