On Mon, 28 Jul 2025 06:57:42 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> If JVMTI `StopThread` is done when the thread is in certain various states >> (but not all states), after the `async` exception is delivered and handled, >> hotspot leaves the thread's `interrupted` flag set. The end result is the >> next time the thread does something like `Thread.sleep()`, it will >> immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the >> `JavaThread::handle_async_exception()` after an `async` pending exception >> has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out >> with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set >> prior to the issuing of the `StopThread()` (this concern was raised by >> @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class >> `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` >> implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by >> the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the >> `JavaThread::handle_async_exception()` is a right thing to do even though it >> was set before the call to `JavaThread::install_async_exception()`. Also, it >> has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the >> issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test >> `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: implemented a suggestion: do not set interrupt flag at all FWIW the way this used to work in the past for the blocking methods is that "stop" would install the pending-async-exception and interrupt the thread to unblock it. The thread doing a sleep/park/wait would see that it was interrupted and proceed to throw `InterruptedException`, and in the process clear the interrupt flag (as per the spec). But when we attempted to return to Java from `_thread_in_vm` we would see the pending-async-exception and replaced the pending IE with the the async one (ThreadDeath usually). But if the thread was not blocked in an interruptible blocking method then it would have the interrupt state set. So we basically have always behaved this way and I'm wondering what is driving us to change this behaviour now? FWIW I think the fix is reasonable to avoid messing with the interrupt flag, but the fact Alan seems to want the "stop" to not interrupt at all makes me wonder how stop would then actually work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3130992741
