On Fri, 18 Jul 2025 18:44:45 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` > > Thank you for the comments and suggestions! > I'll give it a try to get rid of the interrupt flag setting. > @sspitsyn It might be useful to reach out to the IDEs to see what they are > doing. From a quick test with IntelliJ then it appears to invoke both > StopThread and InterruptThread when "Exception to Throw" is used. In that > case, it means that Thread.sleep will wakeup, even if StopThread doesn't > interrupt. Good suggestion, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3101724868
