JDK-6789220 : CMS: intermittent timeout running nsk/regression/b4796926
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs14,hs20,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic
  • Submitted: 2008-12-26
  • 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 7 Other
7Fixed hs21Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
nsk/regression/b4796926 timeouts on linux-amd64 with 
-server -Xcomp -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
HS14-b09 / JDK7-b42: Promotion: 64bit (product)

I narrowed this to 
JAVA_OPTS="-XX:+UseConcMarkSweepGC -Xcomp"
both options are necessary. 
(this is 64bit Server instance only, so "-d64 -server" are not necessary)

Not reproduced with /net/vmsqe.russia/export/jdk/re/7/promoted/ea/b41/binaries/linux-amd64

The test takes just a few seconds to run if everything is ok,
so it may be considered as timeout after, say, 30 seconds.
jstack -f produces a lot of heap walking exceptions,
it also mentions 4 BLOCKED threads and no deadlocks, 
I'm not sure whether this may be trusted.
Only kill -9 is able to kill the java process.

The test just creates and interns 2000000 of strings to exhaust the PermGen.
It is very simple and single threaded, just checks that there's no hangs or crashes. I tried running it with a smaller 4MB PermGen (probably, default is 64 fot this configuration), it hangs too just a bit faster. 

see comments on how to reproduce this.

SUGGESTED FIX I have a fix out for review. It disables background compilation for anything in java.lang.ref.Reference, including the ReferenceHandler class, even if running with -Xcomp.

WORK AROUND Enable background compilation with -XX:+BackgroundCompilation.

EVALUATION A deadlock. The ReferenceHandler threads owns the pending_list_lock and triggers a compile (it's unclear which method is being compiled, but that can be ignored). There is no profiling information for the target method, so the compiler tries to allocate a methodDataOop in the perm gen. However, the perm gen is full, so it triggers a GC, which must acquire the pending_list_lock. The test is run in -Xcomp mode so BackgroundCompilation is disabled, and thus the ReferenceHandler thread waits for the compile to finish, the compile waits for GC to finish, and GC waits for the pending_list_lock.