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