Does it have to be Thread.sleep(1) or is even Thread.yield() slow? Attila
Fredriksson, Christian <[email protected]> ezt írta (időpont: 2025. nov. 21., P, 18:52): > Hey, > > > > I believe I have found a bug with JDK 25 and virtual threads, but will > need some guidance in what information I need to provide in order to file a > bug. > > > > Short version: after changing from JDK 21 to JDK 25, doing Thread.sleep(1) > in a virtual thread now sometimes takes up to 60 seconds (!). > > > > Long version: > > > > I recently updated an application from Java 21 to 25 and started seeing a > very negative performance impact. > > > > The application in question runs ca 20 long running virtual threads which > basically does the following: > > > > while (true) { > > doTrivialWork(); > > Thread.sleep(1); > > semaphore.acquire(); > > } > > > > I.e. do trivial work, sleep 1 ms, wait on a semaphore to be woken by > another thread, and then loop again. After long investigation I finally > realized that it was the Thread.sleep that sometimes took significantly > longer with Java 25 than Java 21. > > So I timed it, basically just this: > > > > while (true) { > > doTrivialWork(); > > var start = System.nanoTime(); > > Thread.sleep(1); > > var end = System.nanoTime(); > > System.out.println("delay=" + (end - start)); > > semaphore.acquire(); > > } > > > > And let it run >1 million times. > > > > With JDK 21 and either virtual threads or platform threads, or with latest > JDK 25 and platform threads, it works fine and the Thread.sleep(1) finishes > according to the following: > > > > 99,5% finish within 2 ms > > 0,4% finish within 4 ms > > Worst case 80 ms > > > > But with latest JDK 25 and virtual threads, it’s significantly worse: > > > > 98,0% finish within 2 ms > > 0,3% finish within 4 ms > > 0,5% taking over 1000 ms > > A few hundred occurrences over 60 seconds (!) > > > > The only change between these runs is JDK version and platform vs virtual > threads. > > > > Increasing jdk.virtualThreadScheduler.parallelism and > jdk.virtualThreadScheduler.timerQueues makes no difference. > > There are no jdk.VirtualThreadPinned or jdk.VirtualThreadSubmitFailed > events in JFR. > > > > Additional information: > > The application is running in a pod on k8s with 1 CPU allocated to it. > > No additional arguments for the JDK. > > CPU utilization is less than 15%. > > GC happens very infrequently (many minutes apart). > > > > > > [image: VOLVO CAR CORPORATION] <http://volvocars.com/> > > Christian > Fredriksson > > > T +46 734 63 71 06 > *[email protected] > <[email protected]>* > > VOLVO CAR CORPORATION > Connected Car Cloud > *volvocars.com <http://volvocars.com>* > > Registered Office Göteborg, Sweden > Registration No. 556074-3089 > > > > >
