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