###@###.### 2002-08-07

While chasing the following bug:

4701980 2/2 HPROF: -Xrunhprof option crashes and restarts S1AS app server

I wrote a test case to look for memory leaks when running a JVM/PI
agent. This test case has a simple algorithm:

1) allocate 1MB chunks until the heap runs out of memory
2) find a working block size < 1MB that can be allocated
3) allocate and free the working block size for N seconds
4) verify that the heap still has < 1MB left

When the test is run without any VM options, an OutOfMemoryError will
be quickly thrown:

    % java -version
    java version "1.4.0"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
    Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
    % java b4727676
    b4727676: starting test.
    Allocated 62MB before getting OutOfMemoryError.
    Remainder of test will run for 30 seconds.
    Working block size is 786432 bytes.
    Could not allocate 786432 bytes after 0 attempts.
    Unexpected exception: java.lang.Exception: b4727676: test FAILed.
    Exception in thread "main" java.lang.Exception: b4727676: test FAILed.
            at b4727676.main(b4727676.java:15)

When the test is run with the '-XX:MarkSweepAlwaysCompactCount=1' option,
then the test passes:

    java -XX:MarkSweepAlwaysCompactCount=1 b4727676
    b4727676: starting test.
    Allocated 62MB before getting OutOfMemoryError.
    Remainder of test will run for 30 seconds.
    Working block size is 786432 bytes.
    Allocated and released working block 1323 times.
    Heap still has < 1MB of memory.
    b4727676: test PASSed.

The default value of MarkSweepAlwaysCompactCount is 4 which means that
dead objects are only compacted every fourth GC (maybe full GC). This
can lead to unpredictable results in low memory situations. It may even
been the root cause for some of our spurious OutOfMemoryError bug
reports.

I have attached the test as b4727676.java.