While making an attempt to replace the ASCII fast loop in `String.encodeUTF8_UTF16` I noticed that altering the shape of the code so that char c is scope local to each loop helps the performance of the method by helping C2 optimize each loop better. I narrowed it down to something as straightforward as this:

```
diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
index abb35ebaeb1..f84d60f92cc 100644
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -1284,14 +1284,17 @@ public final class String
         int sp = 0;
         int sl = val.length >> 1;
         byte[] dst = new byte[sl * 3];
- char c;
- while (sp < sl && (c = StringUTF16.getChar(val, sp)) < '\u0080') {
+ while (sp < sl) {
+ char c = StringUTF16.getChar(val, sp);
+ if (c >= '\u0080') {
+ break;
+ }
             // ascii fast loop;
             dst[dp++] = (byte)c;
             sp++;
         }
         while (sp < sl) {
- c = StringUTF16.getChar(val, sp++);
+ char c = StringUTF16.getChar(val, sp++);
             if (c < 0x80) {
                 dst[dp++] = (byte)c;
             } else if (c < 0x800) {
```

Results on a few micros I'm updating to better stress this code --
Baseline:
```
Benchmark (charsetName) Mode Cnt Score Error Units
StringEncode.WithCharset.encodeUTF16 UTF-8 avgt 15 171.853 ± 10.275 ns/op
StringEncode.WithCharset.encodeUTF16LongEnd UTF-8 avgt 15 1991.586 ± 82.234 ns/op
StringEncode.WithCharset.encodeUTF16LongStart UTF-8 avgt 15 8422.458 ± 473.161 ns/op
```
Patch:
```
Benchmark (charsetName) Mode Cnt Score Error Units
StringEncode.WithCharset.encodeUTF16 UTF-8 avgt 15 128.525 ± 6.573 ns/op
StringEncode.WithCharset.encodeUTF16LongEnd UTF-8 avgt 15 1843.455 ± 72.984 ns/op
StringEncode.WithCharset.encodeUTF16LongStart UTF-8 avgt 15 4124.791 ± 308.683 ns/op
```

Going back, this seem to have been an issue with this code since its inception with JEP 254 in JDK 9.

The micro encodeUTF16LongEnd encodes a longer string which is mostly ASCII but with an non-ASCII codepoint at the end. This exaggerates the usefulness of the ascii loop. encodeUTF16LongStart tests the same string but with the non-ASCII codepoint moved to the front. This stresses the non-ascii loop. We see that the patch above helps in general, but mainly improves the microbenchmark that spends its time in the second loop.

There's likely a compiler bug hiding in plain sight here where the potentially uninitialized local `char c` messes up the loop optimization of the second loop. I think the above patch is reasonable to put back into the JDK while we investigate if/how C2 can better handle this pattern.