review (M) for 4809552: Optimize Arrays.fill(...)

[Ulf Zibis]

Am 20.08.2010 14:48, schrieb Osvaldo Doederlein:
> 2010/8/20 Ulf Zibis<Ulf.Zibis at gmx.de>:
>    
>> A comment aside:
>> Having:
>>      int[] ia = new int[SIZE];
>>      Arrays.fill(ia, 1234);
>>
>> The 1st line causes the array to be first filled with zeroes according the
>> JLS.
>> The 2nd line causes the array to be *again* filled with 1234's.
>>
>> This situation could be optimized by the JIT in skipping the zero-filling.
>> Maybe this is just done by HotSpot, then forget my 2 cents.
>>      
> I think the zero-filling is already performed as part of memory
> management&  GC, so new[] never needs to zero-fill?
>    

I think, irrespectively from which management already performs the 
zero-filling, it wastes CPU-time, and therefore should be avoided here.

-Ulf

> A+
> Osvaldo
>
>    
>> 1 cent more:
>> To give programmer better control of that and to enhance the interpreter in
>> the same way, we would need to have an additional syntax, something like:
>> int [] ia = new int[SIZE](1234); // Project Coin candidate!
>>
>> -Ulf
>>
>>
>> Am 20.08.2010 00:11, schrieb Tom Rodriguez:
>>
>> 4809552: Optimize Arrays.fill(...)
>> Reviewed-by:
>>
>> 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.
>>
>> http://cr.openjdk.java.net/~never/4809552
>>
>>
>>
>>      
>
>