On Thu, 20 Nov 2025 15:31:10 GMT, Anton Artemov <[email protected]> wrote:
>> Hi, please consider the following changes: >> >> If suspension is allowed when a thread is re-entering an object monitor >> (OM), then a deadlock is possible: >> >> The waiting thread is made to be a successor and is unparked. Upon a >> suspension request, the thread will suspend itself whilst clearing the >> successor. The OM will be left unlocked (not grabbed by any thread), while >> the other threads are parked until a thread grabs the OM and the exits it. >> The suspended thread is on the entry-list and can be selected as a successor >> again. None of other threads can be woken up to grab the OM until the >> suspended thread has been resumed and successfully releases the OM. >> >> This can happen in two places where the successor could be suspended: >> 1: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 >> >> 2: >> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 >> >> The issues are addressed by not allowing suspension in case 1, and by >> handling the suspension request at a later stage, after the thread has >> grabbed the OM in `reenter_internal()` in case 2. In case of a suspension >> request, the thread exits the OM and enters it again once resumed. >> >> The JVMTI `waited` event posting (2nd one) is postponed until the suspended >> thread is resumed and has entered the OM again. The `enter` to the OM (in >> case `ExitOnSuspend` did exit) is done without posting any events. >> >> Tests are added for both scenarios. >> >> Tested in tiers 1 - 7. > > Anton Artemov has updated the pull request incrementally with one additional > commit since the last revision: > > 8366659: Fixed whitespace error. I'm reading this bug description in JBS: > If suspension is allowed when a thread is re-entering an object monitor (OM), > then a deadlock is possible in two cases: > > 1) The waiting thread is made to be a successor and is unparked. Upon a > suspension request, the thread will suspend itself whilst clearing the > successor. The OM will be left unlocked (not grabbed by any thread), while > the other threads are parked until a thread grabs the OM and then exits it. > The suspended thread is on the entry-list and can be selected as a successor > again. None of other threads can be woken up to grab the OM until the > suspended thread has been resumed and successfully releases the OM. > > 2) The race between suspension and retry: the thread could reacquire the OM > and complete the wait() code in full, but then on return to Java it will be > suspended while holding the OM. I'm not sure the described scenarios above are real deadlocks. The debugger has to be careful with threads suspension and can behave differently. For instance, it can suspend all threads, so no thread can progress with entering OM's. We do not consider it to be a deadlock, right? In a case just a single thread is being suspended by the debugger, other threads can depend on the suspended thread. But we do not consider it to be a deadlock. It is because everything should come to normal after the debugger resumes the suspended thread. So, could you, please, explain a little bit more on the deadlocks above? How the described in the bug scenarios are different from just listed ones? Do I miss anything? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3561786718
