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