On 12/16/25 1:30 PM, Benjamin Peterson wrote:
On Tue, Dec 16, 2025, at 09:25, Patricio Chilano Mateo wrote:
On 12/15/25 8:37 PM, Benjamin Peterson wrote:
On Mon, Dec 15, 2025, at 16:03, Patricio Chilano Mateo wrote:
Hi Benjamin,
This kind of deadlock, where a platform thread is blocked waiting to
acquire a monitor and the successor is an unmounted virtual thread that
cannot run, should be fixed by JDK-8369019.
Thanks for the pointer. So the idea is that "new" waiters on mutexes with
unmounted virtual thread waiters wake up every so often to see if they can run?
Yes, for platform threads (carriers or not) we use timed-parking when
there are unmounted vthreads ahead in the queue to avoid this kind of
deadlock scenarios.
It seems that would dislodge deadlock in the exact scenario I've run into. But
what if the unmounted virtual thread is hanging onto other resources required
by a waiting platform thread?
For example, suppose the unmounted virtual thread had explicitly called
ClassLoader.loadClass. Then, it could be holding a class loading lock or one of
the JarFile/ZipEntry monitors while unmounted. If the platform thread required
one of those mutexes, there would still be a deadlock even if the platform
thread woke from its timed wait.
Yes, 8369019 only addresses the case where the successor is unmounted.
Fixing the case where the owner of the monitor is an unmounted virtual
thread that cannot run is more complex since we would need to detect the
deadlock and allow that particular virtual thread to run.
Patricio
