Thank you Paul for the comments and suggestions!
Add a fix version of 10, then it’s clear on the intent. Once tests are
added :-) we can review for that release.
Yes, right. I've set the fix version to 10 and also added the @since 10
tag.
I've added a couple of test cases to
`test/java/lang/Appendable/Basic.java`, or do you think the appendN()
method worth more testing?
Personally i would use Arrays.fill, i gather the pattern is already recognised:
https://bugs.openjdk.java.net/browse/JDK-4809552
http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5
The advantage of using Arrays.fill is we know that the pattern will be
recognized (if not it’s a bug, and i suppose it could be made intrinsic to wire
up faster). (see -XX:+TraceOptimizeFill). I suspect we should review the
filling optimization to see if it can be enhanced with newer SIMD instructions,
as i gather the current implementation writes a max of 8 bytes at a time (with
an explicit unrolled loop for 32 bytes at a time, containing 4 separate stores).
Okay, I replaced the first loop with a call to Arrays.fill().
Benchmark shows that for size == 1 the overhead is bigger then for
adding exactly one char in a loop.
For anything longer it appears to be faster.
Benchmark (size) Mode Cnt Score Error Units
MyBenchmark.test_0_New 0 avgt 85 0.004 ± 0.001 us/op
MyBenchmark.test_0_New 1 avgt 85 0.016 ± 0.003 us/op
MyBenchmark.test_0_New 5 avgt 85 0.017 ± 0.003 us/op
MyBenchmark.test_0_New 10 avgt 85 0.020 ± 0.004 us/op
MyBenchmark.test_0_New 20 avgt 85 0.021 ± 0.004 us/op
MyBenchmark.test_1_Old 0 avgt 85 0.004 ± 0.001 us/op
MyBenchmark.test_1_Old 1 avgt 85 0.007 ± 0.001 us/op
MyBenchmark.test_1_Old 5 avgt 85 0.029 ± 0.006 us/op
MyBenchmark.test_1_Old 10 avgt 85 0.048 ± 0.010 us/op
MyBenchmark.test_1_Old 20 avgt 85 0.099 ± 0.019 us/op
MyBenchmark.test_2_Solid 0 avgt 85 0.008 ± 0.001 us/op
MyBenchmark.test_2_Solid 1 avgt 85 0.015 ± 0.002 us/op
MyBenchmark.test_2_Solid 5 avgt 85 0.026 ± 0.005 us/op
MyBenchmark.test_2_Solid 10 avgt 85 0.031 ± 0.004 us/op
MyBenchmark.test_2_Solid 20 avgt 85 0.028 ± 0.005 us/op
It’s good that you found places in the JDK, that adds justification for such
methods, especially for BigInteger and that static array of strings full of ‘0’
characters.
The updates to MethodHandleImpl are not perf sensitive, i question the usage
here but it does reduce stuff in the constant pool i suppose.
I think it also improves readability, as it's clear now the amount of
spaces added.
With kind regards,
Ivan
