JDK-8213150 : Add verification for locking by VMThread
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-30
  • Updated: 2019-09-30
  • Resolved: 2019-09-24
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 14
14 b16Fixed
Related Reports
Relates :  
JDK-8213751 - ClassLoaderDataGraph::cld_do() should sometimes require CLDG_lock
Relates :  
JDK-8228901 - Make ClassLoaderDataGraph linked list lock free
Relates :  
JDK-8184732 - Deadlock detection improvements for 'special' locks
Relates :  
JDK-8228901 - Make ClassLoaderDataGraph linked list lock free
Description
Some locks could block the VMThread if held by Java and nonJava threads, like the ClassLoaderDataGraph_lock.  Add some verification so that these locks are not taken while in a safepoint.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a013100f7a35 User: coleenp Date: 2019-09-24 14:53:50 +0000
24-09-2019
The Mutex::_allow_vm_block mostly handles this for the VM thread. If the VM thread takes out a lock, it's checked that _allow_vm_block is true for the Mutex. If a JavaThread takes out a lock, the code in thread->check_for_valid_safepoint_state() verifies that the JavaThread doesn't own any locks that _allow_vm_block, ie that the VM thread could also take. This check was only done for the JavaThread that actually does a VM_Operation or a heap allocation, and not if it takes another lock that can block for a safepoint. Suggested change will make sure no JavaThread holding a lock that block the VM thread can stop for a safepoint. It adds a NoSafepointVerifier when a allow_vm_block lock is taken. With this change, a locking sequence where lock A, B, and C are safepoint checking locks, locks A and B cannot be taken by the VMThread during a safepoint or they will deadlock. A = ClassLoaderDataGraph_lock and B is Module_lock. MethodCompileQueue_lock can also safepoint while being held, but the VM doesn't take this one. Future enhancement to extend the _allow_vm_block to imply also to non-concurrent GC worker threads. Also the list of excepted locks should be reexamined.
20-09-2019
Linked bug where the fix includes adding NoSafepointVerifier while iterating over CLDG.
14-11-2018
There is an existing problem that you're right to worry about in the VM thread doing unloading. Consider: JavaThread - takes out ClassLoaderDataGraph_lock (setting owner, ignore sneaking) to iterate over the CLDG, then safepoints while holding the lock VMThread at safepoint does either 1 or two things: 1. Calls the HeapDumper or JFR and tries to iterate over the CLDG, but is blocked at the safepoint. 2. Does class unloading and breaks the CLDG links that the iterator is using.
31-10-2018