class loading deadlock

[Patricio Chilano Mateo]

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