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