Name: dkC59003 Date: 06/09/99



JDK releases 1.1.6, 1.1.7, 1.1.8 and 1.2 fail against the following
test when executed under Win32 with JIT on:
    ${TESTBASE}/src/nsk/stress/memory/memleak004
where:
    TESTBASE=/net/sqesvr/vsn/testbase/testbase_nsk

I have tried "memleak004" on the following computers:
- 350MHz Pentium-II, RAM 128Mb, Windows NT 4.0 SP3
- 166MHz Sparc Ultra-1, RAM 128Mb, Solaris 2.5.1

The test allocates all available memory in heap, then releases all that
memory, and again tries to allocate (rather small) amount of memory.
The test is treated failed, if VM fails to allocate the last small amount
of memory. Since there are tons of memory just released, such failure
apparently implies poor performance of garbage collector.

Test may also fail by throwing OutOfMemoryError while trying to
return exit code with the invocation of:
    System.exit(exitCode + 95)
In this case, that OutOfMemoryError exception also implies GC poor
performance.

The test fails against JDK 1.1.5, 1.1.6, 1.1.7, 1.1.8, and 1.2 with JIT on,
and passes when JIT is off. However, I guess this is not JIT failure. The
problem looks like GC failure revealed by JIT, which is faster and therefore
is more exacting than interpreter.

However, all these versions of JDK (1.1.5, 1.1.6, 1.1.7, 1.1.8, and 1.2)
pass "memleak004" under Sparc both with JIT on and with JIT off.

Earlier versions of JDK (1.1, 1.1.2, 1.1.3, 1.1.4) containing no JIT pass
"memleak004" both under Sparc and under Win32; except of JDK 1.0.2, which
fails on Sparc and crashes under Win32 while trying to execute "memleak004".

Note, that JDK 1.2.2 and 1.3 classic VM crash under "memleak004";
and HotSpot 1.0 and 1.3 (the last is built into JDK 1.3) also crash
under "memleak004" and fail under "memleak001". See the bug reports:
  #4245057 (P2/S3) VM crashes when heap is exhausted
  #4239841 (P1/S5) 1.1: poor garbage collector performance

The source of "memleak004.java" is attached to bug #4245057

======================================================================