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

[thurston N]

Ron,

What would be the minimum # of virtual threads you would need to provide
useful data so that you could investigate?
1K? 10K? or even more?

-T

On Fri, Jan 6, 2023 at 11:55 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> On 6 Jan 2023, at 19:48, Robert Engels <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/bc0c3ff6/attachment.htm>