Interesting profile session

[Alan Bateman]

On 24/06/2024 23:03, Robert Engels wrote:
>
> The VT latency is a couple of orders of magnitude higher than the 
> platform latency.
>
> I suspect that what is happening is that the virtual threads are 
> parking waiting for work too soon - or that the read & writes are 
> always causing a context switch - regardless of if the call is very 
> short (room in the kernel socket buffers).
>
> Can you suggest any remedies? It feels like the scheduler needs some 
> heuristics on average call time to determine and a spin loop to avoid 
> this sort of thing.
>
There may be a combination of things here. From the stack traces, this 
looks like JDK 21 + macOS. There has been significant changes to both 
the scheduler (ForkJoinPool) and the I/O poller mechanism since then.  
Would you have time to out the latest EA build [1] to see if you get 
similar latency? It would be interesting to see data with 
-Djdk.pollerMode=1 and 2 (the default on macOS is "a"). Also would be 
useful to see `jcmd <pid> Thread.vthread_summary` output while the 
benchmark is running as that will reveal more about the scheduler and 
how many virtual threads are blocked on socket I/O.

[1] https://jdk.java.net/loom/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240625/79e94ed9/attachment-0001.htm>