This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reconsidering gcjx
>>>>> "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