[External] : Re: effectiveness of jdk.virtualThreadScheduler.maxPoolSize

[Ron Pressler]

On 6 Jan 2023, at 19:48, Robert Engels <rengels at ix.netcom.com<mailto:rengels at ix.netcom.com>> wrote:

The point is that spin locks are valid. If used with vthreads you will quickly lock the pool - if the unlocker is behind the others. With time sharing that shouldn’t happen.


With time sharing you might get some desired behaviour only if the number of threads is quite small, and we already offer a solution for that that I think is better overall than adding time-sharing to virtual threads (although I’d say that if you have a system that’s frequently overcommitted, spin locks are *not* the construct you should use).

But please, we’ve done all these thought experiments and tests for years. I am asking you to talk about a problem you’ve actually faced with virtual threads for which you think changes to virtual threads are the right solution.

What we’re lacking isn’t ideas or hypotheses. The team working on virtual threads has worked on concurrency for many, *many* years (not just in Loom). What we’re lacking is data about usage of virtual threads in the field. If you’d like to help and shape what future features we add, that’s the way to do it.

— Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230106/6f86b03e/attachment.htm>