class loading deadlock

[Patricio Chilano Mateo]

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.

> On 12/15/25 10:47 AM, Benjamin Peterson wrote:
>>> On Mon, Dec 15, 2025, at 02:40, Alan Bateman wrote:
>>>> On 15/12/2025 05:41, Benjamin Peterson wrote:
>>>>> Greetings,
>>>>> I saw class initialization will be preemptible in many cases in JDK 26, which is exciting. I believe my application is hitting a deadlock due to virtual threads pinned in class loading on OpenJDK 25.0.1.
>>>>>
>>>>> I captured a stack dump of the deadlocked application, and I can share the interesting parts of the dump. For background, there are 32 cores, so the virtual thread scheduler pool has 32 carrier threads.
>>>> The startup when using MR JARs is indeed complicated.
>>> It looks to me like there's a potential problem anytime class loading can share an exclusive resource with a non-classloading path. (In this stack dump, the CleanerImpl list.)
>> Yes, class loading has a similar issue to class initialization since
>> native frames in the stack prevent threads to be unmounted.
> Any plans in the works to remove those native frames or make them unwindable somehow?
Nothing planned yet but it’s something we may look into.

Patricio