On Wed, 31 Dec 2025 08:08:49 GMT, Alan Bateman <[email protected]> wrote:
> A regression since we changed the VirtualThread implementation to use use FJP
> delayed task handling (JDK-8351927) in JDK 25.
>
> If a virtual thread does a timed-park, followed immediately by an
> untimed-park, while racing with both an async unpark and the execution of
> cancelled timeout-task, then it is possible for the virtual thread to get
> stuck in the parked state. More specifically, it is possible for stars to
> align to create the scenario where parkTimeoutExpired makes available the
> parking permit but it doesn't continue the thread because it has moved on to
> an untimed-park. A small oversight that crept in when the timeout support
> was migrated to use the new delay scheduler.
>
> Testing: tier1-5. New stress tests added, and existing stress test
> TimedWaitALot updated.
src/java.base/share/classes/java/lang/VirtualThread.java line 920:
> 918: private void parkTimeoutExpired() {
> 919: assert !VirtualThread.currentThread().isVirtual();
> 920: unpark(true);
@AlanBateman There's a slight semantic difference here now, where
parkTimeoutExpired can now transition from both PARKED and TIMED_PARKED where
before it could only transition from TIME_PARKED. Is this change intentional,
and if not, it might be better to duplicate the logic in parkTimeoutExpired and
unpark (but filtering on TIMED_PARKED and PARKED respectively).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29011#discussion_r2662139857
