JDK-6922246 : Deadlock during intensive class loading in parallel
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2010-02-02
  • Updated: 2012-02-01
  • Resolved: 2010-12-07
Related Reports
Duplicate :  
JDK-6988439 - Parallel Class Loading test deadlock involving MethodData_lock and Pending List Lock
Relates :  
JDK-6964458 - Reimplement class meta-data storage to use native memory
Description
For quite a while, across different VM testruns rare timeouts in some PCL tests have been observed. 
The hang was reproduced with jdk7b79 on linux-i586.
"-server -Xcomp -XX:+UseConcMarkSweepGC" VM options were used.

It's really rare - it takes ~10k runs to get a hang, so I haven't tried other JDK/VM versions/VM options so far. 

Java & native stack traces are attached.

How to reproduce:
	1) ssh vmsqe-core2q-15
	2) cd /net/vmsqe.russia/export/home/vi158347/PCL
	3) run rerun.sh multiple times 

The following tests are affected:
	runtime/ParallelClassLoading/delegate-system/dynamic-init/abstract   
	runtime/ParallelClassLoading/delegate-system/dynamic-init/inner-complex
Comments
SUGGESTED FIX diff --git a/src/share/vm/oops/instanceRefKlass.cpp b/src/share/vm/oops/instance RefKlass.cpp --- a/src/share/vm/oops/instanceRefKlass.cpp +++ b/src/share/vm/oops/instanceRefKlass.cpp @@ -438,6 +438,11 @@ void instanceRefKlass::oop_verify_on(oop } } +bool instanceRefKlass::owns_pending_list_lock(JavaThread* thread) { + Handle h_lock(thread, java_lang_ref_Reference::pending_list_lock()); + return ObjectSynchronizer::current_thread_holds_lock(thread, h_lock); +} + void instanceRefKlass::acquire_pending_list_lock(BasicLock *pending_list_basic_ lock) { // we may enter this with pending exception set PRESERVE_EXCEPTION_MARK; // exceptions are never thrown, needed for TRAPS ar gument diff --git a/src/share/vm/oops/instanceRefKlass.hpp b/src/share/vm/oops/instance RefKlass.hpp --- a/src/share/vm/oops/instanceRefKlass.hpp +++ b/src/share/vm/oops/instanceRefKlass.hpp @@ -84,6 +84,7 @@ class instanceRefKlass: public instanceK static void release_and_notify_pending_list_lock(BasicLock *pending_list_basi c_lock); static void acquire_pending_list_lock(BasicLock *pending_list_basic_lock); + static bool owns_pending_list_lock(JavaThread* thread); // Update non-static oop maps so 'referent', 'nextPending' and // 'discovered' will look like non-oops diff --git a/src/share/vm/oops/methodOop.cpp b/src/share/vm/oops/methodOop.cpp --- a/src/share/vm/oops/methodOop.cpp +++ b/src/share/vm/oops/methodOop.cpp @@ -283,6 +283,12 @@ void methodOopDesc::print_invocation_cou // Build a methodDataOop object to hold information about this method // collected in the interpreter. void methodOopDesc::build_interpreter_method_data(methodHandle method, TRAPS) { + // Do not profile method if current thread holds the pending list lock, + // which avoids deadlock for acquiring the MethodData_lock. + if (instanceRefKlass::owns_pending_list_lock((JavaThread*)THREAD)) { + return 0; + } + // Grab a lock here to prevent multiple // methodDataOops from being created. MutexLocker ml(MethodData_lock, THREAD);
01-12-2010
SUGGESTED FIX See entrry#1 in Comments Section for a suggested fix.
18-10-2010
EVALUATION deadlock involving PLL and MethodData_lock.
03-02-2010