RFR JDK-7143928 : (coll) Optimize for Empty ArrayList and HashMap
mike.duigou at oracle.com
Tue Apr 2 19:24:46 UTC 2013
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.
On Apr 2 2013, at 02:12 , Patrick Wright wrote:
> 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