+1 Paul.
> On 2 Feb 2016, at 19:41, Aleksey Shipilev <aleksey.shipi...@oracle.com> wrote: > > 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 >
