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.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.
