EA builds with changes to object monitor implementation to avoid pinning with virtual threads

[Alan Bateman]

On 28/02/2024 05:31, Patricio Chilano Mateo wrote:
> The reason why you see this difference is because with platform 
> threads all 1000 threads will be started and will wait simultaneously, 
> as releasing the monitor on wait() allows another thread to enter it 
> and wait() too. For virtual threads, since we still pin on 
> Object.wait(), we can only run as many threads as workers in the FJP. 
> So the code will behave like running in batches, where after the first 
> batch finishes waiting, the next one will run. We actually compensate 
> on Object.wait() until a max pool size of 256, which will give you 
> around 4 batches, so that explains the 4x-5x you are seeing. If you 
> increase the wait time you will see this more clearly. This behavior 
> will be fixed once we remove pinning on Object.wait(). As for the 
> difference between virtual threads themselves against jdk21 I see a 
> difference too. I'll need to investigate a bit more to check exactly 
> where the overhead is coming from.

It's an unusual test. One thing that would be interesting to look at 
what actual wait duration is. The creation of 1000 platform threads 
takes some time and a lot of the threads will already be in the wait set 
by the time that the main thread enters the monitor and notifies. This 
will have the effect that many, maybe all, of the platform threads don't 
actually wait 100ms. With JDK 21 and the Loom EA builds then at most 256 
threads will be in the wait set. The other thing is that the virtual 
threads contending on the monitor enter will unmount in the Loom EA 
builds whereas the pinning at contented monitorenter with JDK 21 means 
that it is no rescheduling whatsoever going.

-Alan