> On 18 May 2016, at 14:09, Aleksey Shipilev <aleksey.shipi...@oracle.com> > wrote: > > Hi, > > We have been waiting for this for at least 8 weeks, waiting for Jigsaw > to settle in, and hs-main -> jdk9/dev integration to happen that brings > a few testbug fixes into the jdk9/dev. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148604 > > Webrev: > http://cr.openjdk.java.net/~shade/8148604/webrev.01/ > (the change is XS, but impact is M) >
+1 I think this is reasonable as this execution mode has been soaking for a while with existing tests, and is easy to revert if there are issues. Paul. > Targeted benchmarks show significant improvements with the > MH_INLINE_SIZED_EXACT strategy, see the bug for the test results. > Performance improvements are due to these reasons: > > *) it does not rely on OptimizeStringConcat in C2, but instead does > lift up the concatenation into the Java code, spelling it out with > java.lang.invoke building blocks. This also helps to improve C1 > performance significantly; > > *) it uniformly covers the cases that OptimizeStringConcat does not > cover, e.g. non-int/char arguments where OptimizeStringConcat bails, etc; > > *) it uniformly covers the Compact Strings (JEP 254) changes, e.g. > selecting the final coder for the concatenated String, and calling > appropriate coder-specific routines from JDK. Doing this in Java has the > apparent benefit of piggy-backing on normal Java code profiling to > figure out the hot branches -- a luxury OptimizeStringConcat-constructed > code lacks. > > Unfortunately, we cannot test this with our regular performance testing, > because it requires tests compiled with -target 9. The only easy target > we have now is javac, and switching the concat strategy does not regress > it (see JDK-8148605). > > MH_INLINE_SIZED_EXACT is functionally tested routinely with > java/lang/String/concat/ jtregs on all platforms. > > Testing: java/lang/String/ jtregs; JPRT -testset hotspot > > Thanks, > -Aleksey >
