In other words, we are introducing something similar to a new bytecode, 'string concat'. Therefore, we might want to employ some trick to declare the intent of concatenating strings in bytecode, and then expand that intent in runtime. Asking users to recompile their Java programs for performance is not friendly, and it also explodes the testing matrix, since JVMs should recognize all the variants of the generated bytecode. Users generally expect the same bytecode to run faster on newer JVMs. When we consider changing anything in javac, it seems inconvenient to change the compiler and the bytecode shape every time we want to improve performance. It is tempting to change the translation in javac itself see, e.g., the recent proposal on the compiler-dev list.

Those optimizations, while fruitful, are fragile and difficult to extend and maintain see, e.g., JDK-8043677, JDK-8076758, and JDK-8136469. The -XX:+OptimizeStringConcat option enables aggressive optimizations in the JIT compiler, which recognize StringBuilder append chains and do the presizing and in-place copying. Sometimes this translation is not optimal, and sometimes we need to presize the StringBuilder appropriately. Startup time and time to performance do not regress beyond reasonable levels.Ĭurrently javac translates String concatenation into StringBuilder::append chains. String concatenation performance does not regress. The intent is to change the bytecode shape at most once in any major Java release. Success MetricsĪ stable, future-proof bytecode sequence is generated by javac.

It is not a goal to: Introduce any new String and/or StringBuilder APIs that might help to build better translation strategies, revisit the JIT compiler's support for optimizing String concatenation, support advanced String interpolation use cases, or explore other changes to the Java programming language. Producing (and possibly switching to) the optimized translation strategies is a stretch goal for this JEP. Multiple translation strategies should be tried as the motivational examples for this work.

Lay the groundwork for building optimized String concatenation handlers, implementable without the need to change the Java-to-bytecode compiler. This will enable future optimizations of String concatenation without requiring further changes to the bytecode emitted by javac. Change the static String-concatenation bytecode sequence generated by javac to use invokedynamic calls to JDK library functions.

Java string concat