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.