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

[Serguei Spitsyn]

On Fri, 31 May 2024 23:55:20 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
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: refactored def and use of process_pending_interp_only()

> I'm not sure I follow the test logic. Its summary says "Verifies that MethodExit events are delivered on both carrier and virtual threads", but now it just ignores MethodExit requested for carrier thread in breakpoint_hit1.
Then there is no sense to request the event on carrier thread.
> Per the test summary I'd expect the test should test MethodExit for carrier thread, but then java part needs to force unmount.

As we already agreed I've filed the cleanup test bug:
[8333459](https://bugs.openjdk.org/browse/JDK-8333459) cleanup and check MethodExit events are posted on carrier threads in MethodExitTest

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

PR Comment: https://git.openjdk.org/jdk/pull/19438#issuecomment-2146254345