[External] : Re: : Re: Project Loom VirtualThreads hang

Ron Pressler ron.pressler at oracle.com
Fri Jan 6 19:47:07 UTC 2023


Absolutely! Once you report a problem you encounter with virtual threads, we’d be able to prioritise it and find mechanisms that would benefit everyone. Even if they don’t benefit everyone we’d still love to do them (with the right priority, as we get many such requests).

As I said, we’re working to add support for custom schedulers (that could also be used for core affinity), which are certainly an advanced feature and not for the average web application, but we’re only able to work on them because we have concrete problems that we can try to solve. As long as there is no actual problem in front of us, we’re simply incapable in providing any mechanism to solve that non-problem, regardless of priority.

So in some situations I might say, that’s interesting but not a high priority. But if you’re not reporting a problem — one that we determine should be solved by virtual threads rather than some other feature — there’s literally nothing we can do, other than keep asking you to report real problems.

— Ron

> On 6 Jan 2023, at 19:39, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> I could go into a long description of the 64 core machines we used for hft along with the native thread prioritization we added - along with multiple specialized lock-free queues along with core affinity and numa aware scheduling all to reduce latency and increase throughput. 
> 
> I think a lot of those techniques still apply to vthreads and having it in the platform would benefit everyone. 



More information about the loom-dev mailing list