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