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

[Richard Reingruber]

On Tue, 19 Mar 2024 17:46:31 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> 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`

I think this would require hoisting the `ThreadInVMfromNative` out of the loop with the `check_exception_and_log` call but then the thread would be in `_thread_in_vm` when doing the `GetObjectArrayElement` jni call which would be wrong.

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

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