axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 11945] - Too much memory and time spent parsing large message
Date Fri, 14 Feb 2003 20:45:06 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11945>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11945

Too much memory and time spent parsing large message





------- Additional Comments From Eric.D.Friedman@wellsfargo.com  2003-02-14 20:45 -------
I have a thought on why this might be happening.  In Java 1.4, the 
implementation of java.lang.StringBuffer.setLength() was changed.  It used to 
be possible to recycle StringBuffers by invoking setLength(0), which would, as 
a side effect, shrink the capacity of the buffer back to the default size of 
16, allowing the larger char array to be GC'ed.

As of Java 1.4, this is no longer true, and so recycled StringBuffers can leak 
memory.  This is currently one of the top 25 bugs on Sun's BugParade, and it's 
had a big impact on the memory profile of existing code, such as JDOM, which 
use this technique.

I see that Axis also has this problem:  SimpleDeserializer's reset() method 
uses setLength(0) to recycle the "val" stringbuffer.  Under Java 1.4, this may 
trigger the memory leak.  

Sun's position (see the bug parade for details) is that the new behavior is 
what was originally specified and so people should not cache StringBuffers in 
this way.  

Replacing the setLength(0) with a call to new StringBuffer() in 
SimpleDeserializer might help with the memory consumption problem reported here.

Mime
View raw message