On Tue, 26 May 2026 13:15:19 GMT, Patricio Chilano Mateo <[email protected]> wrote:
> In JDK-8311218, processing of self suspend operations was deferred while > holding the `interruptLock` monitor of a virtual thread to avoid possible > deadlocks. In particular, suspending a thread while holding the > `interruptLock` of a given virtual thread would cause that virtual thread to > block in `VirtualThread.unmount`, preventing it from completing the unmount > transition. That in turn would block the resumer thread, since it needs to > wait until no virtual thread is in a transition, leading to a deadlock. We > need to do the same deferral in `MountUnmountDisabler::start_transition`, as > this is also a suspend-checking point. > > There are no obvious unmount points leading to > `MountUnmountDisabler::start_transition` while in these critical regions. But > with the changes in JDK-8369238, class initialization was added to the set of > possibilities. In fact, I was able to create a test that reproduces the > deadlock by triggering contention during initialization of class > `java.util.Locale` in `appendCarrierInfo`. Regardless of this case though, > the `VirtualThread` code could change so we need to guard against this. > > Together with JDK-8375362, this issue shows that we need to skip the suspend > check for the same cases where we skip processing of self suspend operations > in the handshake code. So I grouped these together under > `should_defer_self_suspend` and updated the relevant call sites. > > The patch includes a test that deadlocks as described above without this fix. > I also tested the changes in mach5 tiers1-6. > > Thanks, > Patricio > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). src/hotspot/share/runtime/javaThread.hpp line 791: > 789: } > 790: > 791: bool should_defer_self_suspend() const { I'm struggling to understand what "self-suspend" means in this context. In particular the general inclusion of the jni check doesn't seem applicable to all the places this method gets checked. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31281#discussion_r3309649071
