Allocation of array copy can be eliminated in particular cases
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Wed Nov 20 13:49:01 UTC 2019
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.
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