-
Bug
-
Resolution: Fixed
-
P3
-
9
-
b105
-
Verified
The failure happens with MH_INLINE_SIZED_EXACT strategy and -XX:-CompactStrings, because this strategy builds the byte[] storage completely by itself.
In doing that, it figures out the coder for the final String, but it starts with coder=0, which happens to be String.LATIN1. However, with -XX:-CompactStrings, every String should be String.UTF16. This is not a problem for most concats that capture Strings arguments, because that argument will promote the coder to UTF16. But, in our current scheme, we can request concat expression without Strings, e.g. two *characters*, which escapes the promotion. In the end, the strategy sometimes builds a broken byte[] array, and fails either with AIOOBE, or the garbled String.
The fix is to start with the initial coder that depends on Strings.COMPACT_STRINGS field.
In doing that, it figures out the coder for the final String, but it starts with coder=0, which happens to be String.LATIN1. However, with -XX:-CompactStrings, every String should be String.UTF16. This is not a problem for most concats that capture Strings arguments, because that argument will promote the coder to UTF16. But, in our current scheme, we can request concat expression without Strings, e.g. two *characters*, which escapes the promotion. In the end, the strategy sometimes builds a broken byte[] array, and fails either with AIOOBE, or the garbled String.
The fix is to start with the initial coder that depends on Strings.COMPACT_STRINGS field.
- duplicates
-
JDK-8148760 java/lang/String/concat/ImplicitStringConcatShapes.java fails with "java.lang.IllegalStateException: Expected = T, actual = "
-
- Closed
-
-
JDK-8148762 java/lang/String/concat/ImplicitStringConcatManyLongs.java fails with ArrayIndexOutOfBoundsException
-
- Closed
-