RFR: 8327990: [macosx-aarch64] Various tests fail with -XX:+AssertWXAtThreadSync [v3]

[Tobias Holenstein]

On Wed, 13 Mar 2024 13:53:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 160:
>> 
>>> 158:   ResourceMark rm(THREAD);
>>> 159:   // WXWrite is needed before entering the vm below and in callee methods.
>>> 160:   MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, THREAD));
>> 
>> I understand you placed this here to cover the transition inside `create_classes_array` and the immediate one at line 170, but doesn't this risk having the wrong WX state for code in between?
>
> I've asked this myself (after making the change).
> Being in `WXWrite` mode would be wrong if the thread would execute dynamically generated code. There's not too much happening outside the scope of the `ThreadInVMfromNative` instances. I see jni calls (`GetObjectArrayElement`, `ExceptionOccurred`) and a jvmti call (`RetransformClasses`) but these are safe because the callees enter the vm right away. We even avoid switching to `WXWrite` and back there.
> So I thought it would be ok to coarsen the WXMode switching.
> But maybe it's still better to avoid any risk especially since there's likely no performance effect.

Or could the  `ThreadInVMfromNative tvmfn(THREAD);` in `check_exception_and_log` be move out to `JfrJvmtiAgent::retransform_classes`?  And then only use one `ThreadInVMfromNative` in `JfrJvmtiAgent::retransform_classes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18238#discussion_r1530831165