On Apr 2 2013, at 10:55 , Martin Buchholz wrote: > Thanks for the research. > It seems like hotspot is recognizing and optimizing fill loops, rather than > intrinsifying calls to Arrays.fill itself (good!).
Why wouldn't doing both be better? > Anyways, I'd still like the "simple" fill loops in ArrayList to stay > unchanged. Using Arrays.fill is only slightly more readable. Part of the goal of the change was to make the intent clearer. I'll improve the comments instead. > There would > be more of a case for fill if it was an actual array class instance method. Maybe for Java 9.... Mike > > > > 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 >>
