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

Hui Shi hshi at openjdk.java.net
Wed Jun 2 00:53:31 UTC 2021


On Wed, 2 Jun 2021 00:48:44 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> 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.

Release/fastdebug tier1/2/3 tested.
Fastdebug Tier1/2/3 with option "-XX:-TieredCompilation -Xbatch" also tested.

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

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


More information about the hotspot-compiler-dev mailing list