RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite

[Richard Reingruber]

On Thu, 14 Mar 2024 14:49:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> I noticed a few more asserts  (assert(_wx_state == expected) failed: wrong state)   in the jfr area  (jdk tier3 jfr tests).
> E.g. 
> 
> 
> V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
> V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
> V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
> V  [libjvm.dylib+0x91a578]  JfrRecorderService::emit_leakprofiler_events(long long, bool, bool)+0xcc
> 
> 
> 
> and 
> 
> 
> V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
> V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
> V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
> V  [libjvm.dylib+0x8d7f74]  JfrJavaEventWriter::flush(_jobject*, int, int, JavaThread*)+0xf8
> j  jdk.jfr.internal.JVM.flush(Ljdk/jfr/internal/event/EventWriter;II)V+0 jdk.jfr at 23-internal
> j  jdk.jfr.internal.event.EventWriter.flush(II)V+3 jdk.jfr at 23-internal

> > @MBaesken found 2 more locations in jvmti that need switching to `WXWrite`
> > ```
> > JvmtiExport::get_jvmti_interface
> > GetCarrierThread
> > ```
> > Both use `ThreadInVMfromNative`.
> 
> Should we address those 2 more findings in this PR ? Or open a separate JBS issue ?
> 

I'm leaning towards fixing all locations in this PR even though this will prevent clean backports. Would that be ok?

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1999168860