On Fri, 31 May 2024 23:55:20 GMT, Serguei Spitsyn <sspit...@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
