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