On Tue, 11 Jan 2022 12:30:44 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps > the performance of the method by helping C2 optimize each individual loop > better. > > Results on the updated micros: > 19-b04: > > Benchmark (charsetName) Mode Cnt Score > Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 164.457 ± > 7.296 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2294.160 ± > 40.580 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 9128.698 ± > 124.636 ns/op > > > Patch: > > Benchmark (charsetName) Mode Cnt Score > Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 131.296 ± > 6.693 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2282.750 ± > 46.891 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 4786.965 ± > 64.896 ns/op > > > Going back this seem to have been an issue since this method was introduced > with JEP 254 in JDK 9: > > 8u311: > > Benchmark (charsetName) Mode Cnt Score > Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 194.057 ± > 3.913 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 3024.860 ± > 88.386 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 5282.849 ± > 247.230 ns/op > > 9: > > Benchmark (charsetName) Mode Cnt Score > Error Units > StringEncode.encodeUTF16 UTF-8 avgt 15 148.481 ± > 9.374 ns/op > StringEncode.encodeUTF16LongEnd UTF-8 avgt 15 2832.754 ± > 263.372 ns/op > StringEncode.encodeUTF16LongStart UTF-8 avgt 15 10447.115 ± > 408.338 ns/op > > > (Interestingly JDK 9 seem faster on some of the micros than later iterations, > while slower on others. The main issue is the slow non-ASCII loop, where the > patch speeds things up ~2x. With the patch we're significantly faster than > both JDK 8 and 9 on all measures.) > > There's a JIT compiler bug hiding in plain sight here where the potentially > uninitialized local `char c` appears to mess up optimization of the second > loop. I'll file a separate bug for this (a standalone reproducer should be > straightforward to produce). I think this patch is reasonable to put back > into the JDK while we investigate if/how C2 can better handle this kind of > condition. It might also be easier to backport, depending on whether the C2 > fix is trivial or not. This pull request has now been integrated. Changeset: c3d0a940 Author: Claes Redestad <redes...@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/c3d0a94040d9bd0f4b99da97b89fbfce252a41c0 Stats: 88 lines in 2 files changed: 45 ins; 4 del; 39 mod 8279833: Loop optimization issue in String.encodeUTF8_UTF16 Reviewed-by: shade, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7026
