RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes

[Chris Plummer]

On Tue, 28 May 2024 22:24:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review the following `interp-only` issue related to carrier threads.
> There are 3 problems fixed here:
>  - The  `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter.
>  - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. 
>  - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted.
>  
>  The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio.
>  
>  Testing:
>  - Ran new test case locally
>  - Ran mach5 tiers 1-6

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 201:

> 199: 
> 200:   // need to reset this value after the breakpoint_hit1
> 201:   received_method_exit_event = JNI_FALSE;

There was a loom-dev email thread regarding this last year. Seems related. I had concluded that the way the test was written that no MethodExit event should have been received. I'm not sure if I missed something in my analysis or if this failure is a result of your changes:

https://mail.openjdk.org/pipermail/loom-dev/2023-August/006059.html
https://mail.openjdk.org/pipermail/loom-dev/2023-September/006170.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1619356206