United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6330863 vm/gc/InfiniteList.java fails intermittently due to timeout problems
JDK-6330863 : vm/gc/InfiniteList.java fails intermittently due to timeout problems

Details
Type:
Bug
Submit Date:
2005-09-30
Status:
Closed
Updated Date:
2012-10-01
Project Name:
JDK
Resolved Date:
2012-03-24
Component:
hotspot
OS:
solaris,windows_2003,generic,solaris_10,windows
Sub-Component:
gc
CPU:
x86,sparc,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0u7,6,6u3,6u4,6u4p,7
Fixed Versions:
hs23 (b16)

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

Sub Tasks

Description
Problem Description 	: vm/gc/InfiniteList.java fails intermittently due to timeout problems

Tested_Java_Release   	: 1.6.0
Tested_Build          	: B52
Operating System	: Linux, Solaris X86, Windows
Test cases		: vm/gc/InfiniteList.java
Results Location      	:  http://vmsqe.sfbay/nightly/TL/results/1.6.0-auto-270/ServerVM/64BITLINUX-AMD64/mixed/SERVICE/VMJTREG_REGRESSION-TLNIGHTLY-SERVICE-ServerVM-mixed-64BITLINUX-AMD64-2005-09-28-00-51-23/analysis.html
Error Message		: See Below

----------System.err:(0/0)----------
result: Failed. Execution failed: Program `/var/tmp/fhsu/Work/JDK/TLNIGHTLY/SERVICE/solaris-sparc/bin/java' interrupted! (timed out?)


test result: Failed. Execution failed: Program `/var/tmp/fhsu/Work/JDK/TLNIGHTLY/SERVICE/solaris-sparc/bin/java' interrupted! (timed out?)
~
~

                                    

Comments
EVALUATION

I think this is at least partially due to the way parallel compaction deals with
the young gen.  When copying from a young gen space (e.g., eden or from) to the
old gen, *all* live objects in the space must fit into the old gen; otherwise,
none of them will be copied.  This is because par compaction operates on
'regions' of the heap and copying only part of a space would require extra
bookkeeping (or some good luck).

A scavenge, if it were done, would be able to promote some things into the
old gen.  Even though scavenge before full gc is enabled, the scavenge code
bails out because the estimated amount of bytes promoted is > the amount of
free space in the old gen (in PSScavenge::should_attempt_scavenge()).

I expected the gc overhead limit to kick in, since we are spending nearly all
our time in GC and not collecting anything.  We should get an OOME because we
are spending too much time in GC.  Update after a conversation with the
implemtor of the overhead limit:  the overhead limit is not triggered because
there is too much free space in the old generation (more than 2%).

Could modify the policy so that when the estimated bytes to promote is > the
free space in the old gen, a scavenge is skipped only if the last scavenge
was not skipped for the same reason.  In other (simpler) words, don't skip
consecutive scavenges.
                                     
2006-08-14
WORK AROUND

1.  Add the command line option
    -XX:GCHeapFreeLimit=<N>
Here <N> is a percentage from 0-100 that defines the maximum percentage of free
space in the heap allowed when throwing an OutOfMemoryError because the JVM is
spending "too much" time in GC.  Recommend value of <N> to workaround this bug
is in the range 10-40; the exact value is dependent on the relative sizes of the
young and old generation.  Note that this simply causes the JVM to throw an
OutOfMemoryError earlier than it currently does because the GC overhead is too high;
it doesn't change the way the collector behaves.

2.  Reduce the value of PromotedPadding to 1 or 0 (the default value is 3).  Use the
command line option
    -XX:PromotedPadding=1
PromotedPadding is used when deciding whether to perform a Young GC or a Full GC.
A smaller value may allow Young GCs to be attempted instead of Full GCs as the
heap becomes more full.

Both the above are only partial workarounds; they will not solve the problem for
all applications.
                                     
2007-12-22
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/23c0eb012d6f
                                     
2012-02-17
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/23c0eb012d6f
                                     
2012-02-18
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/23c0eb012d6f
                                     
2012-03-22



Hardware and Software, Engineered to Work Together