JDK-6988439 : Parallel Class Loading test deadlock involving MethodData_lock and Pending List Lock
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs17.1,hs20,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2010-09-29
  • Updated: 2012-02-01
  • Resolved: 2011-03-08
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 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Related Reports
Duplicate :  
JDK-7009149 - Hang on class loading/initialization involving GC locker
Duplicate :  
JDK-6922246 - Deadlock during intensive class loading in parallel
Relates :  
JDK-6692906 - CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time
Relates :  
JDK-7011862 - java/util/concurrent utilities need to handle StackOverflowError:Class loading hang with clss21201m1
Description
Testsuite name: VM
JDK/JRE tested: 1.6.0_22 b05_j4b 
java options: -server -Xmixed -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
OS/architecture: solaris10_x86 
Reproducible: Sometimes (fails 1 of 10 times)
Reproducible on machine: stt-18.russia.sun.com stt-91.russia.sun.com
Is it a platform specific regression: need to be investigated
Is it a new platform support: N
Is it a Regression: No this is not a regression, test fails on 6u20b02, 6u21b11_j4b
Test run log location:
http://stt-13.russia/results/1.6.0_22/b05_j4b/vm/solaris10-x86-32_vm.parallel_class_loading.testlist/ResultDir/interface/interface.log

Steps to reproduce: 
ssh stt-robot@stt-91
/net/vmsqe.russia/export/gtee/gee/bin/jdk install_bundles -srcdirbase /net/stt-13.russia.sun.com/export/home0/jdk -release 1.6.0_22 -build b05_j4b -jdkrename false -arch solaris-i586
cd /set/stt/newroot/results/1.6.0_22/b05_j4b/vm/solaris10-x86-32_vm.parallel_class_loading.testlist/ResultDir/interface/
sh rerun.sh

Test always fails on 66 iteration 
log:
Iteration #63 of 100, time left: 51 s
Iteration #64 of 100, time left: 50 s
Iteration #65 of 100, time left: 50 s
Iteration #66 of 100, time left: 50 s

test passes with 
java options: -server -Xcomp -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

Need to be investigated is it reproducable on other platforms.
In light of the evaluation, synopsis changed from:-

   Parallelclass load test fail intermittent with concurrent garbage collector

to:-

   Parallel Class Loading test deadlock involving MethodData_lock and Pending List Lock

thus absolving CMS of all guilt; so help me Lord!
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7cf1a74771e8
25-12-2010
EVALUATION Summary: Don't acquire methodData_lock while holding pending list lock
10-12-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7cf1a74771e8
10-12-2010
SUGGESTED FIX Drop the MethoData_lock around the code that allocates the MDO storage (so that MD_Lock is not held when trying to GC). The MD_Lock should be made a leaf lock or whatever the current terminology is for "don't hold this lock when attempting to allocate or do a GC".
29-09-2010
EVALUATION Attempt to allocate (and initiate GC/acquire PLL) while holding MethodData_lock in one thread deadlocks with ReferenceHandler thread attempting to acquire the MethodData_lock while holding the PLL.
29-09-2010