Re: RFR: 8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer
Thanks Jim! /Claes On 2019-05-09 13:47, Jim Laskey wrote: +1 On May 8, 2019, at 11:49 AM, 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
Re: RFR: 8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer
+1 > On May 8, 2019, at 11:49 AM, 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
Re: RFR: 8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer
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; } }
RFR: 8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer
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