Thanks guys, pushed. -Aleksey
On 02/02/2016 11:07 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > >> On 2 февр. 2016 г., at 22:41, Aleksey Shipilev <[email protected]> >> 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 >>
