class loading deadlock

[Benjamin Peterson]

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

> Would it be 
> possible to reveal a bit more of the stack traces, specifically the call 
> of loadClass?

Every frame above a loadClass call is an application method that doesn't explicitly call loadClass if that's your question. E.g., many of the virtual threads are like this:

#532 "" virtual BLOCKED 2025-12-12T19:38:17.499406589Z
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
    - waiting to lock <java.lang.Object at 110bf5c4>
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
    at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
    at com.mycompany..ExternalStorage.acquireBlockingToken(ExternalStorage.java:237)
   ...

> Also could you capture the output jcmd 
> Thread.vthread_scheduler as that may quickly confirm your analysis.

I definitely will if it's seen again, but unfortunately I forgot it in the heat of the moment.

It might be handy if pinned virtual threads were annotated in thread dumps!

>
> -Alan