Concurrent Mark-Sweep Problems in 1.4.2 VM?

Question

Can someone please tell me why the 1.4.2 JVM seems to ignore VM tuning flags as soon as the -XX:+UseConcMarkSweepGC flag is used?
For example, please run this program (It is intentionally written to run the VM out of memory):
================START================================
import java.util.*;
public class UseMemory {
private ArrayList m_ref = new ArrayList();
public static void main(String args[]) {
UseMemory um = new UseMemory();
int times = Integer.parseInt(args[0]);
int delay = Integer.parseInt(args[1]);
int size = Integer.parseInt(args[2]);
for ( int i = 0; i < times; i++ ) {
byte[] memory = new byte[size];
um.m_ref.add(memory);
try {
Thread.currentThread().sleep(delay);
System.out.println(Runtime.getRuntime().freeMemory());
} catch ( InterruptedException ie ) {
======================END============================
First, run it under the 1.4.1 VM like this:
/jdk1.4.1_05/bin/java -Xmx128m -Xms128m -Xnoclassgc -verbose:gc -XX:NewSize=32M -XX:MaxNewSize=32M -XX:PermSize=32M -XX:MaxPermSize=32M -XX:SurvivorRatio=4 -XX:+DisableExplicitGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=90 -classpath "." UseMemory 1200 100 1024000
The output from the heap printing follows:
=============BEGIN HEAP PRINT====================
Heap
par new generation total 27328K, used 20253K [0x02a60000, 0x04a60000, 0x04a60000)
eden space 21888K, 92% used [0x02a60000, 0x03e27408, 0x03fc0000)
from space 5440K, 0% used [0x03fc0000, 0x03fc0000, 0x04510000)
to space 5440K, 0% used [0x04510000, 0x04510000, 0x04a60000)
concurrent mark-sweep generation total 98304K, used 90000K [0x04a60000, 0x0aa60000, 0x0aa60000)
CompactibleFreeListSpace space 98304K, 91% used [0x04a60000, 0x0aa60000)
concurrent-mark-sweep perm gen total 32768K, used 1129K [0x0aa60000, 0x0ca60000, 0x0ca60000)
CompactibleFreeListSpace space 32768K, 3% used [0x0aa60000, 0x0ca60000)
0.001: [ParNew: 20253K->20253K(27328K), 0.0000643 secs]0.002: [CMS0.010: [dirty card accumulation, 0.0003718 secs]0.011: [dirty card rescan, 0.0026278 secs]0.013: [remark from roots, 0.0003656 secs]0.014: [weak refs processing, 0.0000028 secs]: 90000K->90000K(98304K), 0.0153770 secs] 110253K->110253K(125632K) Heap after GC invocations=1:
Heap
par new generation total 27328K, used 20253K [0x02a60000, 0x04a60000, 0x04a60000)
eden space 21888K, 92% used [0x02a60000, 0x03e27408, 0x03fc0000)
from space 5440K, 0% used [0x03fc0000, 0x03fc0000, 0x04510000)
to space 5440K, 0% used [0x04510000, 0x04510000, 0x04a60000)
concurrent mark-sweep generation total 98304K, used 90000K [0x04a60000, 0x0aa60000, 0x0aa60000)
CompactibleFreeListSpace space 98304K, 91% used [0x04a60000, 0x0aa60000)
concurrent-mark-sweep perm gen total 32768K, used 1129K [0x0aa60000, 0x0ca60000, 0x0ca60000)
CompactibleFreeListSpace space 32768K, 3% used [0x0aa60000, 0x0ca60000)
} , 0.0182148 secs]
=============END HEAP PRINT====================
Notice that the survivor ratio (4) is being used correctly, and that the default max tenuring level (31) is set correctly.
Now let's run this with a 1.4.2_02 VM:
/jdk1.4.2_04/bin/java -Xmx128m -Xms128m -Xnoclassgc -verbose:gc -XX:NewSize=32M -XX:MaxNewSize=32M -XX:PermSize=32M -XX:MaxPermSize=32M -XX:SurvivorRatio=4 -XX:+DisableExplicitGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=90 -classpath "." UseMemory 1200 100 1024000
Here is the output from a verbose GC:
=============BEGIN HEAP PRINT====================
0.766: [GC  {Heap before GC invocations=2:
Heap
par new generation   total 32704K, used 30000K [0x10010000, 0x12010000, 0x12010000)
  eden space 32640K,  91% used [0x10010000, 0x11d5c1f8, 0x11ff0000)
  from space 64K,   0% used [0x11ff0000, 0x11ff0000, 0x12000000)
  to   space 64K,   0% used [0x12000000, 0x12000000, 0x12010000)
concurrent mark-sweep generation total 98304K, used 60089K [0x12010000, 0x18010000, 0x18010000)
concurrent-mark-sweep perm gen total 32768K, used 1008K [0x18010000, 0x1a010000, 0x1a010000)
0.766: [ParNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 30000K->0K(32704K), 0.0701463 secs] 90090K->90089K(131008K) Heap after GC invocations=3:
Heap
par new generation total 32704K, used 0K [0x10010000, 0x12010000, 0x12010000)
eden space 32640K, 0% used [0x10010000, 0x10010000, 0x11ff0000)
from space 64K, 0% used [0x12000000, 0x12000000, 0x12010000)
to space 64K, 0% used [0x11ff0000, 0x11ff0000, 0x12000000)
concurrent mark-sweep generation total 98304K, used 90089K [0x12010000, 0x18010000, 0x18010000)
concurrent-mark-sweep perm gen total 32768K, used 1008K [0x18010000, 0x1a010000, 0x1a010000)
} , 0.0719439 secs]
=============END HEAP PRINT====================
So what in Sam Hain is going on here? Why has my survivor ration been set to be 511? Why has the max tenuring threshold been set to be 0? Who made the decision that I want to run with the 'promote all' JVM GC settings for me? I don't want this. It is killing me.
Oh, one more thing, if I take out the -XX:+UseConcMarkSweepGC flag, then the GC output looks normal with the 1.4.2_04 VM.
Is this a known bug, am I missing something obvious here?
Please help.
Thanks
Andy

Answer 1

We are using
java -version -serverjava version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.4.2_05-b04)
Java HotSpot(TM) Server VM (build 1.4.2_05-b04, mixed
mode)
>
and the issue is still there
Bug 4874782 says that it was fixed for "tiger".
Do we have any options except upgrading to 1.5?
Any plans to fix it for 1.4.2 ?
As I stated earlier, we believe this is fixed in 1.4.2_05.
[For reasons that I do not understand and which are out-of-scope
for me,  the bug-paraed database just shows that this is
fixed in 1.5"tiger". However, I assure you that it's been
fixed in 1.4.2_05.)
i also just verified that it's fixed in 1.4.2_05 using a variety of tests
that vary the heap settings via the command-line options.
If you believe a bug still exists in 1.4.2_<n>, n >= 5,
or in JDK 5.0, please file a bug against HotSpot (hotspot/garbage_collector)
via appropriate channels, including specific details (command-lines
used, behaviour seen) for the problem you are seeing.