Reconsidering gcjx

[Tom Tromey]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> Tom Tromey wrote:
>> While investigating I realized that we would also lose a small
>> optimization related to String "+" operations.  When translating from
>> .java we currently use a non-synchronizing variant of StringBuffer to
>> do this.

Per> In Java-5-mode I would expect ecj to use the unsynchronized
Per> java.lang.StringBuilder.  If not, I'd consider it a bug.

Yeah.  StringBuilder isn't as nice as our private StringBuffer,
though, because it requires copying the character data when toString
is invoked.  IMNSHO this is a design bug, but we're stuck with it.

Per> A desirable optimization would be to convert local (non-escaping)
Per> uses of StringBuffer/StringBuilder to be stack allocated.  You
Per> could even stack-allocate the actual buffer up to a limited size,
Per> only heap-allocating when it gets over that size.

Yeah, that would be good.  We could fix the toString semantics thing
using the same machinery.  I know David Daney was looking in this area
a bit, I don't know what became of it though.

Tom