Re: The problems with StringBuilders...

[Tom Tromey <tromey at redhat dot com>]

>>>>> "David" == David Daney <ddaney@avtrex.com> writes:

David> For the trick I am thinking of, only a very simple type of escape
David> analysis is required.  The only thing you would have to know is if a
David> reference (to StringBu[ild|ff]er) escapes.

David> On a related note:  If someone were to point me to likely places in
David> the back end where something like this could be done, I might try
David> hacking around a bit.

One way to do this would be to write a new optimization pass that
runs on the SSA form.  Then you could do something along the lines of:

  If the StringBuilder (or buffer) was created in this method, and all
  uses of it are of the form x.append(), with a single x.toString(),
  with no uses after that; then replace it with
  gnu.gcj.runtime.StringBuffer

This will eliminate the both synchronization and the copy on toString().

Since StringBuilder and StringBuffer are final classes, all the calls
ought to be direct, so you won't need to mess around with trying to
untangle virtual method calls.

This approach won't work when compiling BC though.  It isn't clear how
much knowledge of the core class library we want to compile into BC
objects.


This transformation can easily be done by hand on user source.  That
can provide a way to test without committing to writing the whole
optimization first.

One question with this and other optimizations is what is a
representative application.  It is easy to construct a micro-benchmark
where the effect can be observed; the question is whether the
resulting maintenance burden is worth the improvement.

Tom