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