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