There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report.
**Java Thread** - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) **VM Thread** - post `JVMTI_EVENT_OBJECT_FREE` - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >From my research, there are three events that may be posted at safepoints, >`JVMTI_EVENT_GARBAGE_COLLECTION_START`, >`JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but >only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. Test: - [x] tier1 - [x] vmTestbase_nsk_jdi - [x] vmTestbase_nsk_jdwp - [x] vmTestbase_nsk_jvmti ------------- Commit messages: - Update comments - v0 Changes: https://git.openjdk.java.net/jdk/pull/7461/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281615 Stats: 25 lines in 1 file changed: 21 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7461.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7461/head:pull/7461 PR: https://git.openjdk.java.net/jdk/pull/7461
