On Tue, 8 Apr 2025 20:05:26 GMT, Viktor Klang <vkl...@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
