RFR: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

Alan Bateman alanb at openjdk.org
Wed Apr 9 05:59:32 UTC 2025


On Tue, 8 Apr 2025 20:05:26 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
>> 
>> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
>> 
>> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
>> 
>> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 889:
> 
>> 887:     private void parkTimeoutExpired() {
>> 888:         assert !VirtualThread.currentThread().isVirtual();
>> 889:         if (!getAndSetParkPermit(true)
> 
> @AlanBateman Would it make sense to test whether the park-permit is false before the LOCK XCHG?

It already does, no CAS if the current value is the new value.

> src/java.base/share/classes/java/lang/VirtualThread.java line 1455:
> 
>> 1453:             return pool.schedule(command, delay, unit);
>> 1454:         } else {
>> 1455:             return DelayedTaskSchedulers.schedule(command, delay, unit);
> 
> @AlanBateman Would it make sense to test if the Scheduler implements ScheduledExecutorService?

Not for now. If a custom scheduler feature is exposed some time then we can think about this topic, it may or may be that the custom scheduler supports delayed tasks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034500634
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034500533


More information about the core-libs-dev mailing list