On Tue, 2 Feb 2021 13:31:58 GMT, Aleksey Shipilev <shade@openjdk.org> 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 ARM32, affected test now passes - [x] Linux x86_64, affected test now passes - [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))
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Add the regression test case
Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/143