Hi, Please review another simple fix in String concat: https://bugs.openjdk.java.net/browse/JDK-8148869
The failure happens because MH_INLINE_SIZED_EXACT strategy has to figure out the coder for the String concat result, as the binary "or" of initial coder and all argument's (possible) coders. And it mistakenly starts with coder=0, which is String.LATIN1. Under -XX:+CompactStrings (default), if all concat arguments can be encoded in LATIN1, it should produce LATIN1 result; and if at least one argument is UTF16, then the result should be UTF16. The trouble comes with -XX:-CompactStrings, which should always produce UTF16 concat result. Then, even if all arguments can be encoded into LATIN1, the result should be UTF16. But it isn't, because the initial coder is always LATIN1! The fix is to make initial coder depend on Strings.COMPACT_STRINGS: http://cr.openjdk.java.net/~shade/8148869/webrev.01/ Since the failure is predicated on -XX:-CompactStrings, our current tests fail only on platforms where CompactStrings are turned off by default, e.g. AArch64. Added a new regression test that concats differently encodeable chars under +|-CompactStrings. Cheers, -Aleksey
