Skip to content

Conversation

@tajila
Copy link
Contributor

@tajila tajila commented Dec 17, 2025

There are currently two paths where the unblocker may spin in a tight loop. The first is if the continuation list is empty and the second is if a virtualThread is waiting on a lock owned by a platform thread. Both of these cases are handled by this PR.

The first case is handled by removing the
(NULL == vm->blockedContinuations) check at the start of the function. The second case is handled by removing the hasPlatformThreadWaiting code and instead notifying the unblocker anytime a platform thread waits on a monitor.

Backport of #22358 and #23116

Fixes ibmruntimes/Semeru-Runtimes#117

There are currently two paths where the unblocker may spin in a tight
loop. The first is if the continuation list is empty and the second is
if a virtualThread is waiting on a lock owned by a platform thread. Both
of these cases are handled by this PR.

The first case is handled by removing the
`(NULL == vm->blockedContinuations)` check at the start of the function.
The second case is handled by removing the hasPlatformThreadWaiting code
and instead notifying the unblocker anytime a platform thread waits on a
monitor.

Signed-off-by: Tobi Ajila <atobia@ca.ibm.com>
@pshipton
Copy link
Member

#23117 needs to be added to this.

@pshipton pshipton marked this pull request as draft December 17, 2025 23:23
Add macros to protect JDK24+ code.

Signed-off-by: Tobi Ajila <atobia@ca.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants