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.


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