United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6789220 CMS: intermittent timeout running nsk/regression/b4796926
JDK-6789220 : CMS: intermittent timeout running nsk/regression/b4796926

Details
Type:
Bug
Submit Date:
2008-12-26
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
linux,generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs14,hs20,7
Fixed Versions:
hs21 (b02)

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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
WORK AROUND

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



Hardware and Software, Engineered to Work Together