I've modified the SwingMark benchmark program to track memory usage. Under jdk 1.1.7 it seems OK, but under jdk 1.2 fcs it seems to leak like crazy. To find the SwingMark benchmark you can look in:

/home/wilsonsd/SwingMarks

When run with the correct command line options, SwingMark will create a text file which shows memory usage. Here is some sample output (along with the command line args to generate it).

java SwingMark -q -r 15 -m 117memory.txt

SwingMark Memory Report

Date: Thu Dec 03 16:10:27 PST 1998
JDK Version: 1.1.7B
JDK Vendor: Sun Microsystems Inc.
JDK Directory: e:\jdk1.1.7\bin\..
VM Info: Undefined
OS: Windows NT version 4.0
Video Bit-Depth: 16 Bits

Used Memory HeapSize
784288 1134584
1031912 1388536
1277448 1703928
1031840 1986552
1032656 1986552
1033136 1986552
1033744 1986552
1033856 1986552
1033872 1986552
1033856 1986552
1033888 1986552
1034072 1986552
1033888 1986552
1034712 1986552
1033840 1986552
1033896 1986552
1034344 1986552
1034288 1986552
1034200 1986552
1034816 1986552

Here is the same report with JDK 1.2 fcs:

SwingMark Memory Report

Date: Thu Dec 03 16:20:44 PST 1998
JDK Version: 1.2
JDK Vendor: Sun Microsystems Inc.
JDK Directory: e:\jdk1.2fcsV\jre
VM Info: Classic VM build JDK-1.2-V, native threads, symcjit
OS: Windows NT version 4.0
Video Bit-Depth: 16 Bits

Used Memory HeapSize
3066768 5660664
3702424 6787064
4329824 7917560
4960104 7995384
5593184 9125880
6223680 10252280
6854552 11382776
7487048 12513272
8126992 13639672
8752608 14770168
9384176 14847992
10013432 15978488
10643864 18153464
11273976 18235384
11903768 19361784
12534024 20496376
13163064 21626872
13792160 21708792
14424128 22839288
15068568 23965688

As you can see the 117 version starts using 700k and grows to about 1 meg. The 1.2 version starts using 3 meg and grows to 15 meg. The 1.2 version will grow until all memory is consumed. It doesn't seem to level out.

steve.wilson@eng

-------------------------------------------

After working on this with Jim Graham, I've reduced the test case to a very small program. Here it is:

-------------------------------------
import java.awt.*;
import javax.swing.*;

class FrameBash {

   public static void main(String[] args) {
      for (int i = 0; i < 20; i++) {
         Frame f = new JFrame();
         // Frame f = new Frame();
         f.pack();
         f.setVisible(true);
         f.setVisible(false);
         f.dispose();
         System.gc();
      }
      System.gc(); // beat the hell out of gc to make sure it happens
      for (int j = 0; j < 5; j++) {
         try {
            Thread.sleep(250);
         } catch (Exception e) {
            e.printStackTrace();
         }
         System.gc();
         System.runFinalization();
      }
      System.exit(0);
   }
}
----------------------------------

Looking at this with the -Xhrof option on the compiler, we find that none of these JFrames are ever GC'd. After tracing through the references it appears that there is an InputMethod pointing to a JRootPane which points to a JFrame. The InputMethod eventually winds up in a static list, which prevents GC. It seems this happens on Win32, but perhaps not Solaris. That needs to be looked into further.

This looks very similar to bug ID# 4193032.
steve.wilson@eng 1999-01-06

==============================================================================
Customer does not believe this bug has actually been fixed. See information
added to 4193022.


sheri.good@Eng 1999-03-23