[External] : Re: Project Loom VirtualThreads hang

[Robert Engels]

I think it would be better to be able to park/unpark on a monitor efficiently. I think the overhead in handling that common case is more significant than expected. 

I like the idea of carrying over the Thread.priority in vthreads to allow finer control over the scheduling. 

> On Jan 5, 2023, at 12:45 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 5 Jan 2023, at 18:01, Sam Pullara <spullara at gmail.com> wrote:
>> 
>> I think the biggest concern of completely moving to virtual threads is that they don't fairly share the CPU when there are more than cores virtual threads. This makes me hesitant to say they are the default.
> 
> Note that existing Java servers also don’t rely on time-sharing even when using platform threads. Non-realtime kernels usually only employ time-sharing when the CPU is at 100%. I think that the vast majority of Java servers don’t run at 100% CPU utilisation, and when they do, I don’t think anyone is particularly happy with the result. In fact, the scheduling offered by fixed thread pools that are commonly used in thread-per-request servers is far *less* “fair”, or shared, than virtual threads.
> 
> It is not hard to add time-sharing to virtual threads, it’s just that I think people have an incorrect impression of how useful time-sharing is for server workloads. BTW, even parallel streams, which are designed for CPU-bound workloads, don’t offer time-sharing. Asynchronous constructs in the JDK or Java libraries don’t offer time-sharing, either.
> 
> We would gladly consider adding time-sharing to virtual threads if anyone finds reasonable workloads where it actually helps considerably. I’m not saying there aren’t any, it’s just that we haven’t seen them yet. Perhaps wider use of virtual threads in the field will expose some.
> 
> — Ron