Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4195507

Large Memory Leak with JDK 1.2fcs

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 1.2.0, 1.2.1
    • Fix Version/s: 1.2.2
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
      2d
    • Resolved In Build:
      1.2.2
    • CPU:
      generic, x86
    • OS:
      generic, windows_nt

      Description

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                stewilso Steve Wilson (Inactive)
                Reporter:
                stewilso Steve Wilson (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: