JDK-6206166 : gc/gctests/Compact/compact004 fails on SLES 9 and RHEL 4.0 with -XX:+UseParNewGC
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Affected Version: 5.0u5,6
  • OS: linux,linux_2.6,solaris_10
  • CPU: generic,x86,sparc
  • Submit Date: 2004-12-09
  • Updated Date: 2012-02-01
  • Resolved Date: 2005-03-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_09Resolved 6 b28Resolved
Related Reports
Duplicate :  
Relates :  
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

    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.


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)

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

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


    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 

    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

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

###@###.### 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

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

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