On Mon, 5 Jan 2026 16:44:17 GMT, Viktor Klang <[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).
It is intentional. Whoever makes available the parking permit must unpark the
virtual thread if it is parked. This includes the untimed, timed, and pinned
cases. In this case, parkTimeoutExpired could be racing with unpark, or a
"cancelled" parkTimeoutExpired could be racing with unpark. The change in this
PR just restores the behavior to what we had before changing it to use the FJP
delay scheduler.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29011#discussion_r2662198773
