RFR: 8267904: C2 crash when compile negative Arrays.copyOf length after loop [v2]

[Hui Shi]

On Tue, 1 Jun 2021 07:56:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Hui Shi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/hotspot/share/opto/library_call.cpp line 4456:
> 
>> 4454:     // 1. Replace CastIINode with AllocateArrayNode's length.
>> 4455:     // 2. Create CastIINode again in arraycopy_move_allocation_here after control flow adjustion.
>> 4456:     Node* init_control = init->proj_out(TypeFunc::Control);
> 
> I would suggest rephrasing the comment to:
> The CastIINode created in GraphKit::new_array (in AllocateArrayNode::make_ideal_length) must stay below the allocation (i.e. is only valid if the allocation succeeds): 1) replace CastIINode with AllocateArrayNode's length here 2) Create CastIINode again once allocation has moved (see below) at the end of this method

Thanks @rwestrel !  Debug build check and comment are updated.

For "Could you use hash_find() instead? hash_find(prev) == hash_find(cur) maybe?"

Previous multiple CastIINodes are different as: 
- In GraphKit::new_array, CastIINode is only recorded for igvn but not transformed.
- In GraphKit::load_array_length, CastIINode is applied "_gvn.transform", which set TypeInt's _widen field as 3.
``` 
267  CastII  ===  263  226  [[]]  #int:0..max-3 !jvms: ZipPath::getFileName @ bci:65 (line 102)
272  CastII  ===  263  226  [[ 210 ]]  #int:0..max-3:www !jvms: ZipPath::getFileName @ bci:76 (line 103)


Updated commit applies "_gvn.transform" on CastIINode created after array allocation too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4238