JDK 20 |
---|
20 b23Fixed |
CSR :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
JDK-8296446 :
|
double_lock_wait was added in JDK 6 to workaround the custom class loader deadlock problem [1] before parallel capable class loaders were added. It's expected that custom class loaders using non-hierarchical class delegation model should migrate to parallel-capable class loaders to avoid the deadlock problem as described in [1]. This double_lock_wait logic should be removed. [1] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html double_lock_wait does the following: // We only get here if this thread finds that another thread // has already claimed the placeholder token for the current operation, // but that other thread either never owned or gave up the // object lock // Waits on SystemDictionary_lock to indicate placeholder table updated // On return, caller must recheck placeholder table state // // We only get here if // 1) custom classLoader, i.e. not bootstrap classloader // 2) custom classLoader has broken the class loader objectLock // so another thread got here in parallel // // lockObject must be held. // Complicated dance due to lock ordering: // Must first release the classloader object lock to // allow initial definer to complete the class definition // and to avoid deadlock // Reclaim classloader lock object with same original recursion count // Must release SystemDictionary_lock after notify, since // class loader lock must be claimed before SystemDictionary_lock // to prevent deadlocks // // The notify allows applications that did an untimed wait() on // the classloader object lock to not hang.
|