RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3]

Alan Bateman alanb at openjdk.org
Mon Jul 28 10:52:58 UTC 2025


On Mon, 28 Jul 2025 06:58:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 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
>
> I've implemented and pushed the suggestion from Patricio. The mach5 tiers 1-6 are clean.
> I'm not sure about correctness of the tweak in the `JavaThread::sleep_nanos()`:
> 
> @@ -2122,6 +2117,9 @@ bool JavaThread::sleep_nanos(jlong nanos) {
>    jlong nanos_remaining = nanos;
>  
>    for (;;) {
> +    if (has_async_exception_condition()) {
> +      return false;
> +    }
>      // interruption has precedence over timing out
>      if (this->is_interrupted(true)) {
>        return false;
> 
> The mach5 tiers 1-6 tests are all passed without this tweak.

> > @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.

It would put the onus on the debugger to interrupt, which I think is the right thing to do. it would remove the interrupt from JavaThread::install_async_exception and would mean no change to JavaThread::sleep_nanos.

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

PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3126657391


More information about the serviceability-dev mailing list