RFR (S) 8148869: StringConcatFactory MH_INLINE_SIZED_EXACT strategy does not work with -XX:-CompactStrings
Aleksey Shipilev
aleksey.shipilev at oracle.com
Tue Feb 2 21:53:47 UTC 2016
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 <aleksey.shipilev at 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
>>
More information about the core-libs-dev
mailing list