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

Alan Bateman Alan.Bateman at oracle.com
Wed Feb 28 13:54:54 UTC 2024


On 28/02/2024 13:17, masoud parvari wrote:
> :
>
> For the size 1000, it hangs most of the time. When it hangs, most of 
> the time I see the line "notified. started ...", but sometimes I don't 
> even see that line meaning the thread who is running the test method , 
> doesn't wake up from sleep at all in some scenarios.
>
> The wait set is also always a lot lower than 256 which I don't 
> understand why. I thought based on the compensation algorithm , I 
> should always see up to 256 threads waiting. Does this mean that 
> releasing the monitor on object.wait() doesn't always wake up threads 
> that are competing to enter the monitor? If you run the same code with 
> platform thread, the wait set is always equal to size.
>
> I even observed hanging on size 200 for example, but it happened way 
> less than size 1000. So I don't know what is the minimum number that 
> can trigger hanging here.
>
> Btw is there any way to override the 256 hard limit of managed 
> blocking through a VM argument or something?

The system property jdk.virtualThreadScheduler.maxPoolSize can be used 
to configured if needed. You'll see this documented in the 
"Implementation Note" section of Thread section.

 From a quick look, your test has 1001 virtual threads where the +1 is 
the virtual thread started in main. This main thread may release its 
carrier several times in this test when in Thread.sleep(5000), 
synchronized (object), or the latch.await(). It will be rescheduled to 
continue when the sleep time expires, it is selected as the successor to 
enter the monitor when some other thread exits, or the latch count goes 
to zero. The 1000 virtual threads may also release their carrier when 
there is contention entering the monitor. If selected as a successor to 
enter then the monitor then they will be unblocked but can only continue 
if there is carrier available. As Patricio mentioned, Object.wait still 
pins in these builds so there will be starvation when all 256 carriers 
are carrying a virtual thread that is blocked in Object.wait.

-Alan



More information about the loom-dev mailing list