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 :  
JDK-7016079 - VM deadlock during intensive parallel class loading
Duplicate :  
JDK-7009574 - G1: nsk/sysdict/vm/stress/withagent hangs up on a lock in ClassLoader
Relates :  
JDK-7037756 - Deadlock in compiler thread similiar to 6789220
Relates :  
JDK-6186200 - RFE: Stall allocation requests while heap is full and GC locker is held
Relates :  
JDK-6539517 - CR 6186200 should be extended to perm gen allocation to prevent spurious OOM's from perm gen
Relates :  
JDK-6782457 - CMS: Livelock in CompactibleFreeListSpace::block_size().
Relates :  
JDK-6736295 - SIGSEGV in product jvm, assertion "these are the only valid states during a mark sweep" in fastdebug
Description
nsk/regression/b4796926 timeouts on linux-amd64 with 
-server -Xcomp -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
during
HS14-b09 / JDK7-b42: Promotion: 64bit (product)
/net/vmsqe.russia/export/jdk/re/7/promoted/ea/b42/binaries/linux-amd64

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.
Comments
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.
27-01-2011
WORK AROUND Enable background compilation with -XX:+BackgroundCompilation.
19-03-2009
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.
19-03-2009