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
