Wolfgang Muees writes:
> > I finally found out the reason for 'memory leak' on my Java program,
> > and the culprit in this case was StringBuffer - implementation.
> >
> > I have a lexer (made with JFLex), that uses StringBuffer for
> > constructing
> > the strings for certain tokens. The StringBuffer is reused so that each
> > time a new such token is getting creted, StringBuffer.setLength(0) is
> > called. However, in Kaffe's implementation at least, the actual length
> > of the buffer is not changed. This wouldn't be a big problem in itself,
> > as there's just one StringBuffer instance... But, alas, as Strings &
> > StringBuffers are optimized so that when new String(StringBuffer) is
> > called, the character array is actually shared between the string
> > and string buffer, until the StringBuffer needs to change the data
> > (or length of the buffer via setLength()). The problem here is that
> > as soon as I encounter a long token (~4000 chars in this case),
> > _all_ tokens after that will use up the same 4k memory
>
> The right solution for this problem is IMO: don't reuse StringBuffer.
> It is designed primary as an input buffer for a single string.
Yesterday I checked in some changes which should alleviate this
problem nonetheless.. please give them a try and let us know if
they help.
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
