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

Tue Sep 9 10:28:47 UTC 2014

Am 08.09.2014 um 20:53 schrieb Jonathan Gibbons:
> For example, in the first few lines of the patch, I found this:
Do you see any semantics change here?

> 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>");

In this special case javac optimizer could first interpret as (as same as we could help it by just 
coding like that):
              StringBuilder sb = new StringBuilder(
                      "<html><body text=#"+textColor+"><table width=\"100%\">");
so no need for an additional implicit StringBuilder. Additionally javac could guess a reasonable 
capacity first.

> 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?
Good example where such optimization would fail. But:
- manual optimization would fail either
- try catch block anyway would have it's own performance cost, maybe more than the additional 
StringBuilder.

Maybe it's not such complicated as we guess to find out if the affected StringBuilder becomes 
reliably unreachable in case of exception, and therefore securely could be "mutated".

> Also, consider the serviceability implications, if a user is stepping through the code with a 
> debugger.
Good point. But I think, we are already used with this when stepping through simple String 
concatenation or wondering on a StringBuilder in exception stack trace, even there is no 
StringBuilder in our code.

-Ulf