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. Should have been:

diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
index 5c175b125dc..5d5316f5f06 100644
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -4397,7 +4397,7 @@ public final class String
      */
     void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) {
         if (coder() == coder) {
- System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder());
+ System.arraycopy(value, srcPos << coder, dst, dstBegin << coder, length << coder);
         } else { // this.coder == LATIN && coder == UTF16
             StringLatin1.inflate(value, srcPos, dst, dstBegin, length);
         }