Optimization question

[Krystal Mok]

Comments inline below:

On Wed, Dec 23, 2015 at 6:13 PM, Vitaly Davidovich <vitalyd at gmail.com>
wrote:

> Hi Vladimir,
>
> On Wednesday, December 23, 2015, Vladimir Kozlov <
> vladimir.kozlov at oracle.com> wrote:
>
>> Unfortunately whole loop unrolling happens after Escape analysis is done.
>> As result we can't eliminate allocations since we don't know which
>> element of arrays is referenced in loop:
>>
>> JavaObject NoEscape(NoEscape) NSR [ 397F 275F 276F 398F [ 197 202 ]]
>>  185      AllocateArray   ===  127  124  178  8  1 ( 111  99  20  98  1
>> 72  1  1  130  1
>>
>> NSR - Non Scalar Replaceable.
>>
>> After loop is unrolled the result is calculated but arrays are still
>> allocated.
>
>
> Ah ok, that's what Kris was saying as well.  But why does unrolling matter
> for this purpose? Even if loop is not unrolled is it not known which
> elements are accessed?
>

When the loop is fully unrolled, the indices of the elements in the array
becomes a compile-time constant.
That, in turn, can be recognized by EA, allowing the array to be scalar
replaceable -- if EA happens after loop unrolling, that is.


>
> Also, what do you mean by "result is calculated"? What result? :)
>

Vladimir is probably talking about the "sum" and "wsum" local variable in
your program is constant folded after loop unrolling.
But the array had to stay.

- Kris


>
>
>> We do remove NSR allocations for boxing objects but not regular
>> allocations:
>>
>>   // Eliminate boxing allocations which are not used
>>   // regardless scalar replaceable status.
>>   bool boxing_alloc = C->eliminate_boxing() &&
>>                       tklass->klass()->is_instance_klass()  &&
>>
>> tklass->klass()->as_instance_klass()->is_box_klass();
>>   if (!alloc->_is_scalar_replaceable && (!boxing_alloc || (res != NULL)))
>> {
>>     return false;
>>   }
>>
>> Only allocation followed by arraycopy skips zeroing, not by fill() call.
>> Arrays.fill() is implemented as loop.
>>
>>   if (init != NULL && init->is_complete_with_arraycopy() &&
>>       k->is_type_array_klass()) {
>>     // Don't zero type array during slow allocation in VM since
>>     // it will be initialized later by arraycopy in compiled code.
>>     slow_call_address = OptoRuntime::new_array_nozero_Java();
>
>
> Hmm, I'm pretty sure fill() following an allocation had the same zeroing
> elision applied to it.  Kris notes the opto is turned off due to
> implementation issues, which would explain why I still see zeroing.
>
> Thanks
>
>>
>> Regards,
>> Vladimir
>>
>> On 12/23/15 4:56 PM, Vitaly Davidovich wrote:
>>
>>> Hi guys,
>>>
>>> Consider code like this:
>>>
>>> static double mean(double[] array, double[] weights) {
>>>       if (array.length != weights.length) throw ...;
>>>       double sum = 0;
>>>       double wsum = 0;
>>>       for(int i = 0; i < array.length; i++) {
>>>            sum += array[i] * weights[i];
>>>            wsum += weights[i];
>>>        }
>>>        return sum / wsum;
>>> }
>>>
>>> static double mean(double[] array) {
>>>       return mean(array, allOnes(array.length));
>>> }
>>>
>>> static double[] allOnes(int n) {
>>>       double[] d = new double[n];
>>>       Arrays.fill(d, 1);
>>>       return d;
>>> }
>>>
>>> Now suppose I call mean(double[]) overload like this:
>>>
>>> double[] d = {1,2,3,4};
>>>
>>> Using 8u51 with C2 compiler:
>>>
>>> 1) it looks like the array allocation from allOnes isn't eliminated.
>>> 2) moreover it looked like array was zeroed (rep stosd with rax holding
>>> zero).  Unless I misread the asm, I thought an
>>> allocation followed by Arrays.fill skips the zeroing?
>>> 3) ideally, this case would reduce to code that just does a plain
>>> unweighted mean with no multiplication by the weight
>>> and no summation for the weighted sum (weight sum is just array
>>> length).  Is this simply too much analysis to ask for?
>>>
>>> Thanks
>>>
>>>
>>> --
>>> Sent from my phone
>>>
>>
>
> --
> Sent from my phone
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151223/b43f85f4/attachment-0001.html>