class loading deadlock

[Benjamin Peterson]

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.

>
>> 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.

Neat. I would follow a bug if there was one.