On Wed, 27 May 2026 18:35:00 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). > > Patricio Chilano Mateo has updated the pull request incrementally with one > additional commit since the last revision: > > add explicit thread->is_disable_suspend() checks > The patch includes a test that deadlocks as described above without this fix. I do not see any test in this patch. Is it expected? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31281#issuecomment-4579655947
