-
Bug
-
Resolution: Fixed
-
P2
-
hs25
-
b31
-
Not verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8014170 | 8 | Mikael Gerdin | P2 | Closed | Fixed | b89 |
Allocation of metadata is protected by the per-cld Metaspace lock.
The allocation paths always take the Metaspace locks with _no_safepoint_check_flag.
De-allocation of metadata is similarly protected by the per-cld Metaspace lock.
However de-allocations use a normal MutexLocker and thereby a different code path in Mutex.
I believe this was safe until recently because we only deallocated metadata from the VM thread while safepointed but with the MethodCounters change we can now end up deallocating metadata while the VM is running.
The allocation paths always take the Metaspace locks with _no_safepoint_check_flag.
De-allocation of metadata is similarly protected by the per-cld Metaspace lock.
However de-allocations use a normal MutexLocker and thereby a different code path in Mutex.
I believe this was safe until recently because we only deallocated metadata from the VM thread while safepointed but with the MethodCounters change we can now end up deallocating metadata while the VM is running.
- backported by
-
JDK-8014170 Possible deadlock with Metaspace locks due to mixed usage of safepoint aware and non-safepoint aware locking
-
- Closed
-
- relates to
-
JDK-8010862 The Method counter fields used for profiling can be allocated lazily
-
- Resolved
-
-
-
- Closed
-