The Java program I used to generate data for the graphs is here: The test itself performs mostly allocations with some deallocations. It originates from, and I've changed one line to print out total time. It prints the number of iterations and the time to do those iterations. The test is all in one function, so it is not likely optimized any at runtime by hotspot (I don't know how to verify this).

The other conditions of the tests were:

I made the following runs:

JDK1.2 classic VM (JIT on)
1 Ran 10 mins (then I stopped it)
2 Ran until Out-Of-Memory (~24 mins)
3 Ran until Out-Of-Memory (~25 mins)

JDK1.2 hotspot VM
1 Ran 10 mins (then I stopped it)
2 Ran until just past classic VMs had Out-Of-Memory (~26 mins) (then I stopped it)
3 Ran until performance was severely degraded and there was no end in sight (then I stopped it)

JDK1.1.6 (Production version, JIT on)
1 Ran until Out-Of-Memory (~49 mins)

The output of the runs were processed with shell scripts I wrote that output was processed with GNUplot to create the graphs.

Here is the first graph:

As you can see, JDK1.2 with hotspot gets far beyond what JDK1.2 without it does, as well as JDK1.1.6. Surprisingly, though 1.1.6 is worse in speed it does better in how far into the test it gets before it gets an Out-Of-Memory error.

The next graph shows how much memory is being used over time:

For JDK1.2 hotspot numbers only come from the GC with compact values, as the intermediate GC values ranged widely and gave no real additional interpretation to the graph. The values are not surprising given the results of the previous graph.

The next graph combines both of the other graphs, removing the time element. It shows memory used by the number of operations performed:

It shows a lot of similarities in memory usage between JDK1.2 Classic VM and JDK1.1.6. The hotspot graphs appear to use a little more memory (based on what the garbage collector reports), but is able to go to its memory limits.