Allocation of array copy can be eliminated in particular cases

Nils Eliasson nils.eliasson at oracle.com
Wed Nov 20 14:36:16 UTC 2019


On 2019-11-20 14:49, Vladimir Ivanov wrote:
> Hi Sergey,
>
>> Is my speculation correct and does it make sence to implement 
>> optimization that turns sequence
>>
>> array -> array.clone() - > clone.length
>>
>> into
>>
>> array -> array.length
>>
>> for the cases clone's visibility scope is predictable?
>
> Considering there's no way to grow/shrink Java arrays, 
> "cloned_array.length => original_array.length" transformation is 
> correct irrespective of whether cloned variant escapes or not.
>
> Moreover, the transformation is already there:
>
> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/memnode.cpp#l2388 
>
>
> I haven't looked into the benchmarks you mentioned, but it looks like 
> cloned_array.length access is not the reason why cloned array is still 
> there.

We don't eliminate array allocations that doesn't have a known length 
because they might cause a NegativeArraySize Exception. In this case we 
should be able to prove that the length is positive though.

Anyway - I have an almost finished patch that replace unused array 
allocations with a proper guard.

// Nils


>
> Regarding your other ideas, redirecting accesses from cloned instance 
> to original is problematic (in general case) since compiler has to 
> prove there were no changes in both versions and indexed accesses make 
> it even harder. And safepoints cause problems as well (for 
> rematerialization).
>
> But I agree that it would be nice to cover (at least) simple cases of 
> defensive copying.
>
> Best regards,
> Vladimir Ivanov


More information about the hotspot-compiler-dev mailing list