On Tue, 2 Feb 2021 13:12:53 GMT, Aleksey Shipilev <[email protected]> wrote:
> Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by > default. But the bug is actually generic: > > $ CONF=linux-x86_64-server-fastdebug make run-test > TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" > > test Insert.insertOffset(): failure > java.lang.AssertionError: expected [??abc] but found [efabc] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at org.testng.Assert.assertEquals(Assert.java:188) > at Insert.insertOffset(Insert.java:45) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > I believe this is a regression from > [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). > > void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int > length) { > if (coder() == coder) { > System.arraycopy(value, srcPos, dst, dstBegin << coder, length << > coder()); > } else { // this.coder == LATIN && coder == UTF16 > StringLatin1.inflate(value, srcPos, dst, dstBegin, length); > } > } > > When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), > then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. > > Additional testing: > - [x] Linux x86_64 `tier1` default, passes > - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two > testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), > [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) > - [x] Linux ARM32, affected test now passes Looks good, thanks for fixing this. Should we add an explicit run with -CompactStrings to the Insert.java test? That'd have caught this issue sooner - perhaps already by the GA testing. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/143
