Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Mon Sep 8 18:39:44 UTC 2014

On 08.09.2014 21:50, Jonathan Gibbons wrote:
> Yes, but is this really a big enough performance and footprint pain 
> point to be worth addressing in javac itself?
> We're now talking about some specific code construction like
>     new StringBuilder().append(a + b + c)
> Any other case where the string builder can be observed externally 
> cannot be subject to the proposed optimization. The use case is now 
> really getting pretty specific.
Not so specific at least in jdk code:
> -- Jon
> On 09/08/2014 10:41 AM, Guy Steele wrote:
>> Good point, but counterpoint: it might be acceptable to have modified 
>> the string buffer in situations where throwing an exception would 
>> always cause the string buffer to become inaccessible.
>> —Guy
>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com> wrote:
>>> It would be inappropriate/incorrect to apply the optimization as 
>>> described.
>>> The JLS requires that the argument to a method call should be 
>>> computed before invoking the method.
>>> Consider the case when one of the expressions in the series of 
>>> string concatenations throws an exception. It would be incorrect to 
>>> have already partially modified the string buffer.
>>> -- Jon
>>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>>> Hi compiler people,
>>>> is there some chance that javac could be enhanced to optimize 
>>>> better as discussed in this thread? Than refactoring of up to now 
>>>> better readable code to ugly StringBuilder at append() code would be 
>>>> superfluous.
>>>> I really like the String concatenation syntax, but unfortunately it 
>>>> often causes slower code and bigger footprint.
>>>> Optimally javac would optimize mixed use of StringBuilder, 
>>>> StringJoiner, concatenation, toString(), append(String), 
>>>> append(Collection) etc. to a single StringBuilder instance, so that 
>>>> the resulting code, JITed or not, will have better performance.
>>>> Additionally javac could guess a reasonable initial capacity from 
>>>> the given source code.
>>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>>> So it's not that the optimization fails but there is no 
>>>>> optimization on them yet.
>>>>> I do see the .append("x") case will be easy to deal with, but it 
>>>>> looks like historically javac has not been a place to do many 
>>>>> optimizations. It mostly converts the java source to byte codes in 
>>>>> a 1-to-1 mapping and let VM do whatever it wants (to optimize). 
>>>>> When you talked about compiling multiple concatenation into using 
>>>>> a single StringBuilder, it's more like choosing the correct 
>>>>> implementation rather than an optimization.
>>>>> I don't expect to see big change on this in the near future, so 
>>>>> shall we go on with the current enhancement?
>>>>> Thanks
>>>>> Max
>>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>> I mean:
>>>>>> It does not output byte code that only uses a single char array 
>>>>>> to compose the entire String in question.
>>>>>> With "optimization fails", I also mean, there is used an 
>>>>>> additional "StringComposer" e.g. another StringBuilder or a 
>>>>>> StringJoiner in addition to the 1st StringBuilder.
>>>>>> -Ulf
>>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>>> Could you please explain what you mean by "javac optimization 
>>>>>>> fails" here?
>>>>>>> -Pavel
>>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>> 4.) Now we see, that javac optimization fails again if 
>>>>>>>> StringBuilder, concatenation, toString(), append(String), 
>>>>>>>> append(Collection) etc. and StringJoiner use is mixed.

Best regards, Sergey.

More information about the compiler-dev mailing list