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
---
There was related discussions on the past
http://mail.openjdk.java.net/pipermail/compiler-dev/2014-February/008491.html
And related issues:
https://bugs.openjdk.java.net/browse/JDK-4947460
https://bugs.openjdk.java.net/browse/JDK-4059189
https://bugs.openjdk.java.net/browse/JDK-6709423
On
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
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
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
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
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
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
FWIW, Google has gotten noticeable performance benefits from a change to
javac's compilation of normal + concatenation, to just presize the
StringBuilder. I haven't had the bandwidth to forward-port that change
yet, unfortunately, but that's a semantics-preserving change that seemed to
us to be
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
It may be worth to compare the performance of alternative
implementations with -XX:+OptimizeStringConcat option turned on.
Sincerely yours,
Ivan
On 30.08.2014 0:53, Ulf Zibis wrote:
Hi compiler people,
is there some chance that javac could be enhanced to optimize better
as discussed in this
It's probably best to teach the JIT to handle more of these cases. The
reason is I don't think the longer compile time will be worth it
considering that, on a large codebase, there will inevitably be lots of
places where these patterns appear but have no dominance at runtime (either
because
12 matches
Mail list logo
