JDK-8330193 : JDWP getLocks() should make sure current thread doesn't grab any more locks
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-04-12
  • Updated: 2025-05-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26Unresolved
Related Reports
Relates :  
JDK-8328866 - Add raw monitor rank support to the debug agent
Description
In the debug agent threadControl module there is an API called getLocks() that grabs any monitor that may be needed during thread suspension, and then releaseLocks() releases them once thread suspension is done. This is to make sure we don't end up suspending a thread that is holding a monitor that we will need later on. A failure to grab all needed monitors can lead to a deadlock.

Once the monitors are grabbed, we should store the current thread in a global and then assert that no more monitors are grabbed by that thread. This would just require debugMonitorEnter() comparing the global to the current thread. It does however need to allow re-entering already held monitors, which requires tracking entry counts for each monitor. This is being added by JDK-8328866 and can be leveraged once it is in place.