-
Enhancement
-
Resolution: Fixed
-
P3
-
9
-
b112
-
x86
When allocating an array of statically-known size, our current hot-path zeroing strategy seems to split out the zeroing into the individual stores when the size is small. However, this does not happen at all for the arrays of non-constant size, which sets us up for the significant penalty when allocating small arrays.
Benchmark:
http://cr.openjdk.java.net/~shade/8146801/EmptyArrayBench.java
http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar
Performance data:
http://cr.openjdk.java.net/~shade/8146801/notes.txt
The crux of the issue seems to be a large "rep stos" setup cost (see [1]). Note that Agner argues [2] that rep instructions are still future-proof, because they allow CPUs to select the appropriate implementation. It seems we only need to cater for the setup costs here. In C2, we avoid "rep stos" on small arrays when the size is known statically. In C1, we always do the looped mov, which is amusingly faster than C2-ish attempt at "rep stos"-ing on small arrays. It might be worthwhile to check the array size in zeroing path, and do the looped initialization for small sizes.
C2 non-constant size = 8: 12.610 ± 0.193 ns/op
http://cr.openjdk.java.net/~shade/8146801/c2-field-8.perfasm
C2 constant size = 8: 4.681 ± 0.135 ns/op
http://cr.openjdk.java.net/~shade/8146801/c2-const-8.perfasm
C1 non-constant size = 8: 6.839 ± 0.103 ns/op
http://cr.openjdk.java.net/~shade/8146801/c1-field-8.perfasm
C1 constant size = 8: 6.843 ± 0.079 ns/op
http://cr.openjdk.java.net/~shade/8146801/c1-const-8.perfasm
[1] http://www.agner.org/optimize/optimizing_assembly.pdf , 17.9, "Moving blocks of data (All processors)"
[2] http://www.agner.org/optimize/optimizing_assembly.pdf , 17.9, "Moving data on future processors"
Benchmark:
http://cr.openjdk.java.net/~shade/8146801/EmptyArrayBench.java
http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar
Performance data:
http://cr.openjdk.java.net/~shade/8146801/notes.txt
The crux of the issue seems to be a large "rep stos" setup cost (see [1]). Note that Agner argues [2] that rep instructions are still future-proof, because they allow CPUs to select the appropriate implementation. It seems we only need to cater for the setup costs here. In C2, we avoid "rep stos" on small arrays when the size is known statically. In C1, we always do the looped mov, which is amusingly faster than C2-ish attempt at "rep stos"-ing on small arrays. It might be worthwhile to check the array size in zeroing path, and do the looped initialization for small sizes.
C2 non-constant size = 8: 12.610 ± 0.193 ns/op
http://cr.openjdk.java.net/~shade/8146801/c2-field-8.perfasm
C2 constant size = 8: 4.681 ± 0.135 ns/op
http://cr.openjdk.java.net/~shade/8146801/c2-const-8.perfasm
C1 non-constant size = 8: 6.839 ± 0.103 ns/op
http://cr.openjdk.java.net/~shade/8146801/c1-field-8.perfasm
C1 constant size = 8: 6.843 ± 0.079 ns/op
http://cr.openjdk.java.net/~shade/8146801/c1-const-8.perfasm
[1] http://www.agner.org/optimize/optimizing_assembly.pdf , 17.9, "Moving blocks of data (All processors)"
[2] http://www.agner.org/optimize/optimizing_assembly.pdf , 17.9, "Moving data on future processors"
- blocks
-
JDK-8148604 JEP 280, Switch to more optimal concatenation strategy
- Resolved
- relates to
-
JDK-8152440 Zero build fails after JDK-8146801
- Resolved
-
JDK-8201193 Use XMM/YMM for objects initialization
- Resolved
-
JDK-8260928 InitArrayShortSize constraint func should print a helpful error message
- Resolved