Allocation of array copy can be eliminated in particular cases

[Vladimir Ivanov]

>> Moreover, the transformation is already there:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/memnode.cpp#l2388
> 
> Comment in line 2389 seems confusing to me:
> 
> // This works even if the length is not constant (clone or newArray).
> 
> When we clone array isn't the length constant and equal to the length of original array? I guess it cannot be different.

In the context of JIT-compilers, a "constant" means "compile-time 
constant" - a value known to JIT-compiler. The constant case is when the 
array has always the same length (e.g., "original_array.length == 0").

What you are describing is an invariant on 2 values: the length of 
original array and the length of cloned array are equal. But everything 
JIT-compiler knows about those values is (1) "original_array.length == 
cloned_array.length"; and (2) "original_array.length >= 0".

>> 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.
> 
> Once I thought that cloned array is retained at run time because it's returned from method in original benchmark:
...
>  From this output I conclude that either I miss something from understanding of how compiler and runtime work, or this is a bug. >
> I will be happy to understand which of the two is correct :)

I assume Nils answered your question why cloning isn't eliminated right now.

Best regards,
Vladimir Ivanov