United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6206166 gc/gctests/Compact/compact004 fails on SLES 9 and RHEL 4.0 with -XX:+UseParNewGC
JDK-6206166 : gc/gctests/Compact/compact004 fails on SLES 9 and RHEL 4.0 with -XX:+UseParNewGC

Details
Type:
Bug
Submit Date:
2004-12-09
Status:
Resolved
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2005-03-17
Component:
hotspot
OS:
linux,solaris_10,linux_2.6
Sub-Component:
gc
CPU:
x86,sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
5.0u5,6
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

Description
--------------------------------------------
Failing Test : gc/gctests/Compact/compact004
JDK          : 1.6.0-b14
flags 	     : -XX:+UseParNewGC 
Platform     : SLES 9 (x86 & amd64), RHEL 4(x86)
--------------------------------------------

Machine Name : opteron004.sfbay
Kernel version : 
Linux version 2.6.5-7.97-smp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Fri Jul 2 14:21:59 UTC 2004

DESCRIPTION OF TEST :
    The test checks that Garbage Collector does not throw any unexpected
    exceptions and errors while compacting the memory. It also implicitly
    checks that work of a GC does not break the JVM.

    The test works with primitive type short. It starts just one thread and
    fills the memory with huge arrays of that type (the size of the arrays
    is based on Runtime.maxMemory() value, so just a few arrays are needed
    to fill the heap until OutOfMemoryError). The arrays are created and
    stored in java.util.Vector. Then null is assigned to even elements of
    the vector to provoke GC to clean the memory. After that the test inserts
    objects of greater size into the same places of the Vector
    (a class that has two fields short[]).

    The test extends nsk.share.gc.MultiThreadStressGCPattern class, so that
    allows a user to run the test for some iterations or for some period of
    time. See javadoc for MultiThreadStressGCPattern and ArgHandler calsses
    for more details.

TESTBASE LOCATION: 
/net/sqe.sfbay/global/nfs/test_results4/VM/UNIFIED-DTF/DTWS/suites/GC_FULLLOOK/testbase

PLEASE NOTE: 
1) This test can be reproduced intermittently (once in 2/3 tries)
2) It passes when -XX:+UseParNewGC is not used.
3) This test also fails on SLES 9 (x86 & amd64), RHEL 4(x86) with 1.5.0 JDK
4) This test passes in SLES 8 (x86 and amd64), and RHAS 3 (x86) with 1.5.0 and 1.6.0 b14 JDK (2.4 kernel)

TO REPRODUCE:
cd /net/jano.sfbay/export/disk20/GammaBase/Bugs/{this_bug_number}/
sh rerun.sh 

Test output:
-----------------------------------------------------------------------
# sh rerun.sh 
Number of threads: 1
Run the test for : 1 iteration(s)
A single thread to eat memory via Algorithms.eatMemory()

Iteration: 0

Size of each brick is 4259840 bytes (2129920 stones).

Exception java.lang.OutOfMemoryError: requested 4259864 bytes for promotion. Out of swap space?

-----------------------------------------------------------------
###@###.### 2004-12-09 02:39:51 GMT


Here's the description from duplicate bug 6216898 which, note,
fails as you'd expect from the evaluation section, on Solaris as well:

Test fails: gc/gctests/Compact/compact001
            gc/gctests/Compact/compact002
	    gc/gctests/Compact/compact003
	    gc/gctests/Compact/compact004
	    gc/gctests/Compact/compact005
	    gc/gctests/Compact/compact006
	    gc/gctests/Compact/compact007
	    gc/gctests/Compact/compact008
	    gc/gctests/Compact/compact009
	    gc/gctests/Compact/compact011
	    gc/gctests/Compact/compact013
	    gc/gctests/Compact/compact014
	    gc/gctests/Compact/compact015
	    gc/gctests/Compact/compact016

switch/mode:  +XX:+UseParNewGC
VM:         Server/-d64
System:     Solaris 10 b74l1 sparc
JDK:        Mustang 6.0 b17


Those tests passed with -XX:+UseParallelGC and -XX:UseSerialGC

DESCRIPTION

    This test is aimed to catch regressions of the bug:

        4404502 Speed.java causes SEGV on first full GC

    The test creates 100 linked list each consisting of 
    10000 nodes. The test is deemed passed if VM does not 
    crash.

    Also, the test passes, if OutOfMemoryError is caught.

Here's one of the .tlog file:
#annotate TEST javaopt=-d64 -server -Xmixed -d64 -XX:+UseParNewGC -XX:SurvivorRatio=6
/net/sqe.sfbay/global/nfs/test_results4/VM/tiger/DTWS/exec1/GC_FULLLOOK-07-WEEKLYmtg-VM-ServerVM-mixed-64BITSOLSPARC5.10-2005-01-10-11-49-02-0444/jdk/solaris-sparc/bin/java -d64 -server -Xmixed -DHANGINGJAVA2695 -d64 -XX:+UseParNewGC -XX:SurvivorRatio=6 gc.gctests.Compact.compact001 -iterations=1 -gcTimeout=5
##Exit status of execution step=1
##!checkExitCode

#Number of threads: 1
#Run the test for : 1 iteration(s)
#A single thread to eat memory via Algorithms.eatMemory()
#
#Iteration: 0
#
#Size of each brick is 4220518 bytes (4220518 stones).
#
#Exception java.lang.OutOfMemoryError: requested 4220544 bytes for promotion. Out of swap space?

Here's the logs:
http://sqeweb.sfbay/st4/VM/mustang/DTWS/results/1.6.0-ea-b17/ServerVM/64BITSOLSPARC5.10/mixed/VM/GC_FULLLOOK-07-WEEKLYmtg-VM-ServerVM-mixed-64BITSOLSPARC5.10-2005-01-10-11-49-02-0444/analysis.html


###@###.### 2005-1-12 23:25:32 GMT
###@###.### 2005-1-12 23:38:29 GMT

******************************************************************************

This problem is reproducible on 1.5.0_05-b03" on Linux AMD 64 machines

                                    

Comments
EVALUATION

Please check the amount of virtual memory available during the test.  
The error message: 

    Exception java.lang.OutOfMemoryError: requested 4259864 bytes for promotion. Out of swap space?

is probably due to running out of swap space for the process.  Linux is notorious for dealing badly with running out of swap space.  So is the JVM.

In particular, if you are running this test while running other tests, the combination may run you out of swap space.
###@###.### 2004-12-09 05:53:17 GMT

I'm going to treat this as the problem where

	thread 1 expands the old gen to get a promotion buffer
	thread 2 gets the expanded space before thread 1 can
	thread 1 thinks the expansion failed and returns an out-of-memory

I'll implement the fix and see.
###@###.### 2004-12-10 17:56:41 GMT
                                     
2004-12-09
WORK AROUND

Set the minimum and maximum heap size to the same value.
This avoids the expansion that can result in the OOM
exception - heap is already expanded to it's limit so
the expansion will not return any space (which could
be stolen by another thread).
###@###.### 2005-1-20 21:29:47 GMT
                                     
2004-12-09



Hardware and Software, Engineered to Work Together