JDK-8149758 : Small arraycopy of non-constant length is slower than individual load/stores
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-02-12
  • Updated: 2018-10-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-6912521 - System.arraycopy works slower than the simple loop for little lengths
Relates :  
JDK-8150730 - Improve performance and reduce variance for AVX-assisted arraycopy stubs
Relates :  
JDK-8148937 - (str) Adapt StringJoiner for Compact Strings
Description
JDK-6912521 added support for exploding arraycopy into the series of individual loads and stores. However, that apparently only works when copy size is statically known. In some interesting cases, it does not, see e.g. JDK-8148937, that uses String APIs doing the arraycopies for trivial delimiters, and that apparently penalizes performance. Benchmark + performance data: http://cr.openjdk.java.net/~shade/8149758/ArrayCopyDynamic.java Runnable JAR: http://cr.openjdk.java.net/~shade/8149758/benchmarks.jar
Comments
From the compiler's side, both C1 and C2 seem to be affected. I'm not sure if it makes sense the runtime team to look into this (or work in collaboration between the compiler and runtime teams). I kept JDK-8150730 at compiler for the same reason.
14-02-2017
Not really sure about "compiler" designation, since arraycopy handling is a cross-cutting issue for the entire runtime.
12-02-2016