To give some context ("Why are you doing this to us?!")
I've extracted a few simple concatenation expressions (most of these are
commonly seen in the JDK sources) to create a reasonably realistic test
to assess String concat bootstrap overheads[1] (timings for a simple
noop and difference within parentheses):
JDK 8: 60ms (60ms, +0ms)
JDK 9: 215ms (86ms, +129ms)
JDK 12: 111ms (43ms, +68ms)
jdk/jdk: 97ms (40ms, +57ms)
+ this: 86ms (40ms, +46ms)
So on a test like this, this little optimization is surprisingly large.
Since we need fewer generated classes under the hood to make up
these expressions, it's also a nice little static and dynamic
footprint improvement.
This also shows there's still some lengths to go to make ISC bootstraps
perfectly neutral relative the StringBuilder chains emitted on earlier
targets. We probably won't get _that_ far, but I also thought we
wouldn't be able to improve much after the optimizations delivered in
JDK 12, so who knows...
Thanks!
/Claes
On 2019-05-08 16:49, Claes Redestad wrote:
Hi,
yet another String concat startup/footprint optimization.
As the subject implies, we could fold the initialLengthCoder it into the
final mixer. This way we end up with one less bound argument into the
larger method handle combinator tree, with fewer species classes and
lambda forms generated as a result. This means a significant speed-up on
several startup and footprint tests, and especially noticeable on
realistic workloads that just have a few different small concat shapes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8223454
Webrev: http://cr.openjdk.java.net/~redestad/8223454/open.00/
Thanks!
/Claes
[1]
public class StringConcatMix {
public static void main(String ... args) {
String s = String.valueOf(args.length);
String concat;
concat = s + s;
concat = "c" + s + "c";
concat = s + "c" + s;
concat = "c" + s + "c" + s;
concat = "c" + s + s + "c";
concat = s + "c" + s + s + "c";
concat = "c" + s + "c" + args.length;
concat = "c" + s + "c" + s + "c" + s;
}
}
