Thanks for the pointer. I had remembered reading this changeset and it has motivated to use Arrays.fill but I could not have found it.
Mike On Apr 2 2013, at 02:12 , Patrick Wright 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
