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