I have no idea. I was just sticking in my two cents’ worth on what is
possible. What is desirable and worthwhile is a much bigger question.
On Sep 8, 2014, at 1:50 PM, Jonathan Gibbons <jonathan.gibb...@oracle.com>
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.
>
> -- 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.gibb...@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@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.zi...@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.zi...@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.
>
