Project Loom VirtualThreads hang

[Robert Engels]

I start with the standard j.u.c containers but I’ve reworked a few for green threads. 

One of the biggest surprises is that synchronized() doesn’t work well with green threads. Changing the code to use a specialized exclusive lock made a huge improvement. 

I plan on working up a post with my summary findings and code samples when I can find some time. 

In general Loom is working really well except for a few surprising cases. My Java server has been able to match the performance of the Go server but not consistently (may be due to GC) but prior the native thread version could only get to within 20% of it - the async version showed more promise but the code is messy. 

Since producer P1 and P2 might send a message to consumer C1 at the same time, there is locking involved. With native threads the only solution was to use a intermediary specialized queue. With threads it is more efficient to use standard locking on the output side. 

The above is evidence that the use case of vthreads is beyond “thousands of threads creating every few seconds” and more efficient user space  synchronization should also be a primary metric. 

> On Jan 3, 2023, at 8:34 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 03/01/2023 14:03, Robert Engels wrote:
>> :
>> 
>> A virtual thread should be far more efficient in regards to user space locking/blocking/wake-up - my tests show only a few % system cpu time. To do this well though the vthread scheduler needs to be super efficient and the locking constructs rewritten knowing they’re on green threads - because the spin time/block decisions are much different (eg upwards of 16 microseconds to perform an os switch to another thread on the cpu vs a few hundred nanoseconds for a green thread switch).
> 
> Yes, the cost model is different so the use of spin loops to reduce parking has to looked at in several places. So what are you testing, is a  j.u.concurrent API or something else? There is some spinning and yield once in APIs such as SQ and LTQ that do need to be re-examined.
> 
> -Alan