JDK-4809552 : Optimize Arrays.fill(...)
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-01-28
  • Updated: 2025-03-10
  • Resolved: 2011-04-23
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.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Causes :  
JDK-8351468 - C2: array fill optimization assigns wrong type to intrinsic call
Relates :  
JDK-6302620 - Range checks are unnecessary in Arrays.fill() when filling an entire array
Relates :  
JDK-6981773 - incorrect fill value with OptimizeFill
Relates :  
JDK-6982370 - SIGBUS in jbyte_fill
Relates :  
JDK-8307683 - Loop Predication should not hoist range checks with trap on success projection by negating their condition
Description
Name: rmT116609			Date: 01/28/2003


DESCRIPTION OF THE PROBLEM :
System.arraycopy() performs brilliantly on Intel/AMD CPUs as it maps right on down to a single REP MOVS instruction. Perhaps an order of magnitude faster than the same thing in a normal loop.

I'd like a System.arrayfill() method that could be built on a REP STOS operation.

(Today I'm initializing buffers for a b-tree. Need to blank-fill the text buffer - a pretty common thing to do. Index efficiency is critical to DB operations, so speed matters here.)

(Review ID: 180473) 
======================================================================
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5
08-10-2010
EVALUATION 4809552: Optimize Arrays.fill(...) Reviewed-by: kvn This adds new logic to recognize fill idioms and convert them into a call to an optimized fill routine. Loop predication creates easily matched loops that are simply replaced with calls to the new assembly stubs. Currently only 1,2 and 4 byte primitive types are supported. Objects and longs/double will be supported in a later putback. Tested with runthese, nsk and ctw plus jbb2005.
09-09-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d6f45b55c972
04-09-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d6f45b55c972
28-08-2010
EVALUATION I've changed the categories to java/hotspot/compiler2.
05-09-2006
EVALUATION The java.util.Arrays.fill(...) family of static methods already provide the functionality desired. Making those methods fast seems like a job for hotspot. I think this CR belongs in java/hotspot/ somewhere; the core library maintainers can't turn those method bodies into one machine instruction. This seems similar to 6431242: Optimize Integer.reverseBytes() 6431243: Optimize Integer.rotateLeft() so I am changing the synopsis to "Optimize Arrays.fill(...)"
05-09-2006