The problems with StringBuilders...

Tue Oct 4 13:40:00 GMT 2005

Escape analysis is an old item on the gcj todo list, fortunately I've
seen it working
in Excelsior JET to say that it really does what it should do
regarding the performance.
Sun has implemented the escape analysis logic in their new 1.6
version, the first fruit to come
is simple lock coarsening (backported to 1.5_05) followed by
uncontended synchronization and stack allocation.
I really like to see this technique build on gcj (gcjx), but that is a
different story, as automatic array bounds check elimination,
runtime generics (when compiling from source), working auto vectorization... :)
On 10/4/05, Andrew Haley <aph@redhat.com> wrote:
> David Daney writes:
> > We had an enlightening (for me anyhow) discussion on IRC about the
> > problems with Sun's new StringBuilder class.
> >
> > Summary:
> >
> > StringBuilder is kind of useless. Because it is unsynchronized, the
> > results of StringBuilder.toString() cannot share the underlying char
> > array (a copy of the array must be made). This is because there are
> > race conditions that would result in a String changing its value after
> > it is created if a copy were not made.
>> I see how this could happen, yes.
>> > Having to copy the contents probably has a much overhead as all the
> > synchronization required by the StringBuffer that it replaces (and
> > that can share the array).
>> I doubt it. I'd like to see some profile measurements to prove it.
> Besides, is there any reason not simply to synchronize
> StringBuilder.toString() ?
>> > TODO:
> >
> > If the compiler could do some sort of escape analysis on the
> > StringBuilder objects,
>> If the compiler could do escape analysis we'd have much better
> performance, for sure. However, inheritance makes this very hard to
> do in most cases. It's on my list.
>> In general, it's really important that when we do performance
> improvements we concentrate on things that can be proved by
> measurement really to help. This is often surprising.
>> Andrew.
>