Adding ASCII fast-paths to the readUTF methods of Data- and ObjectInputStream that reuse intrinsified code used in java.lang.String and related libraries appears to be profitable. The serialized streams use modified UTF-8 so while the code in String isn't directly applicable in full, for ASCII-only data the logic can be shared.

On my M1 MacBook this brings some large speed-ups, while the cost in non-ASCII-cases is negligible:

Name Cnt Base Error Test Error Unit Change
.DataInputStreamTest.readChar 20 5,026 ± 0,040 5,025 ± 0,019 us/op 1,00x (p = 0,916 )
.DataInputStreamTest.readInt 20 2,600 ± 0,019 2,636 ± 0,052 us/op 0,99x (p = 0,020 )
.DataInputStreamTest.readUTF 20 0,086 ± 0,001 0,059 ± 0,001 us/op 1,46x (p = 0,000*)
.DataInputStreamTest.readUTFMixed 20 0,119 ± 0,001 0,113 ± 0,001 us/op 1,05x (p = 0,000*)
.DataInputStreamTest.readUTFMixedSmall 20 0,104 ± 0,011 0,103 ± 0,006 us/op 1,02x (p = 0,626 )
.DataInputStreamTest.readUTFSmall 20 0,104 ± 0,009 0,033 ± 0,000 us/op 3,14x (p = 0,000*)
.ObjectInputStreamTest.readUTF 20 2,705 ± 0,037 0,766 ± 0,003 us/op 3,53x (p = 0,000*)
.ObjectInputStreamTest.readUTFMixed 20 3,262 ± 0,054 3,248 ± 0,018 us/op 1,00x (p = 0,334 )
  * = significant