Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters
Ulf Zibis
Ulf.Zibis at CoSoCo.de
Mon Sep 8 22:58:44 UTC 2014
Much thanks for all your thoughts.
-Ulf
Am 08.09.2014 um 20:53 schrieb Jonathan Gibbons:
> 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.
>
> For example, in the first few lines of the patch, I found this:
>
> diff -r dde9f5cfde5f src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
> --- a/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java Tue Aug 05 19:29:00
> 2014 -0700
> +++ b/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java Sun Aug 10 18:02:01
> 2014 -0300
> @@ -79,25 +79,24 @@
> String textColor = String.format("%06x",
> foreground.getRGB() & 0xFFFFFF);
> StringBuilder sb = new StringBuilder();
> - sb.append("<html><body text=#"+textColor+"><table width=\"100%\">");
> + sb.append("<html><body text=#").append(textColor).append("><table width=\"100%\">");
> for (int i = 0; i < arr.length; i++) {
> if (i % 2 == 0) {
> - sb.append("<tr style=\"background-color: " +
> - evenRowColorStr + "\"><td><pre>" +
> - (arr[i] == null ?
> - arr[i] : htmlize(arr[i].toString())) +
> - "</pre></td></tr>");
> + sb.append("<tr style=\"background-color: ")
> + .append(evenRowColorStr).append("\"><td><pre>")
> + .append(arr[i] == null ?
> + arr[i] : htmlize(arr[i].toString()))
> + .append("</pre></td></tr>");
>
>
> 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?
>
> 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 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.
>>>
>>
>>
>
>
More information about the core-libs-dev
mailing list