On Tue, 29 Jul 2025 07:06:21 GMT, David Holmes <dhol...@openjdk.org> wrote:
> 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? I don't think the current proposed change (which drop's setting the interrupt flag in install_async_exception) will cause a target thread blocked in sleep to wakeup. A target thread blocked in JavaThread::sleep_nanos will wakeup from park_nanos but will just park again with the remaining time. I assume this is the test failures that Serguei mentions. As you noted, the bug is the side effect of setting the interrupt status of a target thread that is not in a InterruptedException throwing method. It may be that the "Throw Exception" feature in debuggers isn't used much and nobody has noticed. If we can reach out the debugger/IDE maintainers then we might be able to a bit more insight into how this is used. In some debuggers you can't use "Throw Exception" (= StopThread) when the target is blocked in the native code or in the VM. When suspended at a breakpoint then it looks like IntelliJ calls both ThreadReference::stop and ThreadReference::interrupt but I can't tell if the latter is conditional or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3133023220
