class loading deadlock

[Benjamin Peterson]

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?

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

>
> Patricio