8373120: Virtual thread stuck in BLOCKED state

[shipilev]

Fixes another Virtual Thread issue that manifests in JDK 25.

Unfortunately, JDK-8369238 adjusted the same block (added interruptible flag). That issue is too large to backport at this time. We might backport it later. But we can fix this particular issue by carefully dealing with interruptible conflict. The code shape looks to be the same and fixes the reproducer.

Additional testing:

• New regression test fails without the fix, passes with it; 1000x iterations
• Linux x86_64 server fastdebug, jdk_loom hotspot_loom, 100x
• Linux x86_64 server fastdebug, java/lang/Thread/virtual/stress/, 500x
• Linux AArch64 server fastdebug, all

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• JDK-8373120 needs maintainer approval
• Commit message must refer to an issue

Issue

• JDK-8373120: Virtual thread stuck in BLOCKED state (Bug - P3 - Approved)

Reviewers

• Patricio Chilano Mateo (@pchilano - no project role)
• Paul Hohensee (@phohensee - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk25u-dev.git pull/379/head:pull/379
$ git checkout pull/379

Update a local copy of the PR:
$ git checkout pull/379
$ git pull https://git.openjdk.org/jdk25u-dev.git pull/379/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 379

View PR using the GUI difftool:
$ git pr show -t 379

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk25u-dev/pull/379.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back shade! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[shipilev]

@pchilano, would be happy to hear what you think here :)

[openjdk]

@shipilev This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8373120: Virtual thread stuck in BLOCKED state

Reviewed-by: pchilanomate, phh

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 62 new commits pushed to the master branch:

• c6590d8: 8377602: Create automated test for PageRange
• c6d47ed: 8373866: Refactor java/net/httpclient/ThrowingSubscribers*.java tests to use JUnit5
• 646e139: 8367531: Template Framework: use scopes and tokens instead of misbehaving immediate-return-queries
• ... and 59 more: https://git.openjdk.org/jdk25u-dev/compare/08a14fd8b53b8cda92933339ba539fb5ff54fd12...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 00: Full (a2a0d68c)

[pchilano]

Looks good, thanks for backporting!

[shipilev]

Thank you for looking! I'll stress test it a bit more and then request approval for 25u.

[shipilev]

Stress tests pass, see PR body. Oh, but we should do JDK 26 first: openjdk/jdk26u#111

[shipilev]

/approval request Fixes another Virtual Threads issue. The issue reproduces in 25u, a regression since JDK 24. The patch does not apply cleanly due to minor conflicts, easy to resolve. Reproducer fails without the fix, passes with it. Stress tests pass. Was in mainline for 1.5 months without bugtail. We expect that users would see this issue in real deployments, if not fixed. Risk is medium: touches VT paths, but it fairly mild manner and fixes the VT corner case.

[openjdk]

@shipilev
8373120: The approval request has been created successfully.

[GoeLin]

Hi @shipilev
Are you sure this needs to go to 25.0.4 (July), would it be fine to defer it by one?
As I understand there are no reports from applications running into this.

[shipilev]

Hi @shipilev Are you sure this needs to go to 25.0.4 (July), would it be fine to defer it by one? As I understand there are no reports from applications running into this.

Yes, this is more in "taking a calculated risk" territory.

We have plenty of internal customers who want stable VT support, and JDK 25 looks the release that unbreaks some of the stuff for them, e.g. the no longer pinning on synchronized. Our experience also shows that if we have seen VT issues in JDK-internal testing (like this one), they would definitely show up in some production environment at scale. It would be even sadder if VT production code that ran reasonably fine on JDK 21, would upgrade to JDK 25 to cover the significant part of VT corner cases, and then run into new regressions in JDK 25 the fix like this addresses. This is why we are even considering to pick it up to Corretto 25.0.3 ahead of upstream :)

But it is ultimately your call as maintainer, we can live with it either way.

[shipilev]

Push approval granted.

/integrate

[openjdk]

@shipilev This pull request has not yet been marked as ready for integration.

[shipilev]

Bots are confused. There is an approval tag on the issue. Trying again.

/integrate

[openjdk]

@shipilev This pull request has not yet been marked as ready for integration.

[shipilev]

Oh wait, I am confused. The backport is not clean, and I though Patricio's review counted as Review. So, I need a Reviewer to step in.

[shipilev]

Thanks!

/integrate

[openjdk]

Going to push as commit 40506bd.
Since your change was applied there have been 62 commits pushed to the master branch:

• c6590d8: 8377602: Create automated test for PageRange
• c6d47ed: 8373866: Refactor java/net/httpclient/ThrowingSubscribers*.java tests to use JUnit5
• 646e139: 8367531: Template Framework: use scopes and tokens instead of misbehaving immediate-return-queries
• ... and 59 more: https://git.openjdk.org/jdk25u-dev/compare/08a14fd8b53b8cda92933339ba539fb5ff54fd12...master

Your commit was automatically rebased without conflicts.

[openjdk]

@shipilev Pushed as commit 40506bd.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.