Thanks for the research. It seems like hotspot is recognizing and optimizing fill loops, rather than intrinsifying calls to Arrays.fill itself (good!).
Anyways, I'd still like the "simple" fill loops in ArrayList to stay unchanged. Using Arrays.fill is only slightly more readable. There would be more of a case for fill if it was an actual array class instance method. On Tue, Apr 2, 2013 at 2:12 AM, Patrick Wright <pdoubl...@gmail.com> wrote: > On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourgès > <bourges.laur...@gmail.com>wrote: > > > > --- > > > > > > 604 Arrays.fill(elementData, newSize, size, null); > > > > > > In performance-critical code I would avoid Arrays.fill because it adds > a > > > bit of overhead (unless it's intrinsified, which I don't think it is). > > > > > > > Last week, I sent few benchmarks I did on array cleaning (zero fill) > > comparing Arrays.fill, System.arraycopy, Unsafe.setMemory ... > > Arrays.fill is the winner (always faster than arraycopy which use native > > code) by 10 - 20% ! > > I suspect aggressive hotspot optimizations (native code ?) because I > agree > > Arrays.fill looks like a stupid for-loop ! > > > > Does somebody have clues explaining the Arrays.fill performance ? > > > > There was at least one round of optimization done by the HotSpot team in > mid-2010 - > "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. " > > see > > http://openjdk.5641.n7.nabble.com/review-M-for-4809552-Optimize-Arrays-fill-td10322.html > > Looks like the change was part of 6u23 > > http://download.java.net/jdk6/6u23/promoted/b03/changes/JDK6u23.b03.list.html > > Could not find anything more recent than that (on a quick mail search) > > Cheers > Patrick >
