Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8146801

Allocating short arrays of non-constant size is slow


    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
    • CPU:


      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.


      Performance data:

      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

      C2 constant size = 8: 4.681 ± 0.135 ns/op

      C1 non-constant size = 8: 6.839 ± 0.103 ns/op

      C1 constant size = 8: 6.843 ± 0.079 ns/op

      [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"


          Issue Links



              • Assignee:
                shade Aleksey Shipilev
                shade Aleksey Shipilev
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: