RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap

Patrick Wright pdoubleya at gmail.com
Tue Apr 2 09:12:49 UTC 2013

On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourgès
<bourges.laurent at 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. "


Looks like the change was part of 6u23

Could not find anything more recent than that (on a quick mail search)


More information about the core-libs-dev mailing list