###@###.### 2002-07-31

J2SE Version (please include all output from java -version flag):
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-
Java HotSpot(TM) Client VM (build 1.4.1-rc-b18, mixed mode

Does this problem occur on J2SE 1.3 or 1.4? Yes / No (pick one)
 No. 1.4 only reports <2MB heap,
     1.4.1 reports > 13MB heap.
  
Operating System Configuration Information (be specific):
  Win2K SP2
  (Same problem can be reproduced on Solaris 8:
   1.4 -
     Got 174 properties
     Used 3520K
   1.4.1 -
     Got 174 properties
     Used 17512K <----- ~5 times

Hardware Configuration Information (be specific):
  dual 866Mhz Pentium IIIs, 1Gb RAM.

Bug Description:
  Memory leak problem when use Hopper build 18. The application itself
  basically parses an XML file and has some reflection based code to turn
  the XML into method calls on an data object.

Steps to Reproduce (be specific):
  1. unjar testcase.jar file
  2. javac *.java
  3. java JDK141Leak

  JDK1.4.1 the app reports it uses > 13Mb heap,
  running same app under 1.4 reports <2Mb heap.

In real life the non-stripped down version parses a bunch of XML
messages using the same technique. Under 1.4.1 it runs out of memory
with a 256Mb heap whereas in 1.4 it doesnt even reach 64mb heap size.

  

###@###.### 2002-08-20

More information from the customer:

After further investigation it has been narrowed the problem down to a
call java.lang.StringBuffer.toString().

However, this call has to take place while parsing an XML file, if
simulate the XML parsing by calling the appropriate methods by hand there
is no leak.

here is the algorithm used as follow:

Use SAX to parse XML file
   If SAX gets a new element, call startElement() method and append XML
      element name onto XPATH
   If SAX gets new characters, call text() and append the characters into
      a StringBuffer
   If SAX gets an end element, call endElement() and use the current XPATH
      to lookup a command pattern and pass it the contents of the current
      StringBuffer. Then remove element name from XPATH.

Its the passing of the contents of the current StringBuffer that is
causing the leak. Look for the PROBLEM comment in PropertyResponseParser.java

New stripped down code is in the attached jar(JDK141LeakV2.jar).

Name: rmT116609 Date: 08/29/2002


DESCRIPTION OF THE PROBLEM :
Refer to bug ID (4724129)
There is a very significant memory leak in the StringBuffer class. I ran my application using -verbose:gc under j2sdk1.4.0 and under j2sdk1.4.1rc and the memory usage went up dramatically in j2sdk1.4.1rc.

I researched the problem in the bug database and saw something about the bug id referring to StringBuffer class and as a test I replace in the j2sdk1.4.1rc rt.jar file the StringBuffer.class from j2sdk1.4.0 class and it went back to normal.

I did a difference on the two classes and the problem appears in the setLength method where the following code:
if (count < newLength) {
if (shared) copy();
for (; count < newLength; count++) {
value[count] = '\0';
}
} else {
            count = newLength;
            if (shared) {
                if (newLength > 0) {
                    copy();
                } else {
                    // If newLength is zero, assume the StringBuffer is being
                    // stripped for reuse; Make new buffer of default size
                    value = new char[16];
                    shared = false;
                }
            }
        }

was replaced in the 1.4.1rc version with:
if (count < newLength) {
if (shared) copy();
for (; count < newLength; count++) {
value[count] = '\0';
}
} else {
            count = newLength;
            if (shared) copy();
        }

I think this is an IMMEDIATE must fix bug! It would be simple to reverse to the previous code for StringBuffer to solve this simple but huge problem!

(Review ID: 163802)
======================================================================