Loom scheduler improvements?

[robert engels]

Hi loom devs - Happy New Year!

I have been digging into loom and testing the performance.

I think I see an area for possible improvement in the scheduler. See the following async profiler capture:



Notice that the most expensive operation in the system is that the ForkJoin worker is parking attempting to schedule work due to contention on the DelayedWorkQueue lock (the vthread is trying to park itself for N nanos). Ordinarily I wouldn’t be too concerned with micro benchmarks, but the primary goal of Loom is efficiency and this seems like it should be fairly straightforward to address with a specialized lock-free structure for use by Loom carrier threads. I have to expect the Loom design is to handle vthreads will a very short runtime until park/reschedule.

As it is, I wrote a specialized lock, rather than using the standard ReentrentLock since the standard always ended up parking the acquiring too soon - only to be awoken nearly immediately, and then rescheduled. It seems better to use some heuristics based on the cost of schedule switch and the expected park time and then spin for N loops prior to parking.

I see the same behavior with both JDK19 and JDK20.

Does the above look reasonable? Any other suggestions?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230102/9017ac83/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 537656 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230102/9017ac83/PastedGraphic-2-0001.png>