[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-compiler-dev
Subject:    Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder p
From:       Sergey Bylokhov <Sergey.Bylokhov () oracle ! com>
Date:       2014-09-09 11:47:50
Message-ID: 540EE8E6.3040801 () oracle ! com
[Download RAW message or body]

On 08.09.2014 22:53, Jonathan Gibbons wrote:
> Sergey,
>
> Many of the suggestions in the webrev change the semantics of the 
> code, and so would not be appropriate for javac to perform automagically.
It is changed but I guess it is safe otherwise this ccan be a problem in 
the fix, but the fix still under review.
> Analyzing the flow to determine it is safe to mutate sb in the face of 
> possible exceptions coming out of methods like htmlize is more than it 
> would be reasonable to do in javac.  For example, what if the for loop 
> were in a try block and the try block referenced sb?
It depends how many man's time spend on such changes, which can be done 
by the javac itself. I see that there is a lot of review requests to 
make some small micro/size optimizations, which can be done automatically.
>
> Also, consider the serviceability implications, if a user is stepping 
> through the code with a debugger.
>
> -- Jon
>
>
> On 09/08/2014 11:39 AM, Sergey Bylokhov wrote:
>> 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:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028142.html 
>>
>>>
>>> -- 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@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.Zibis@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@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.

[prev in list] [next in list] [prev in thread] [next in thread]