[10] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Apr 19 16:45:51 UTC 2017


Hi, Roland

Did you run performance testing?
It could affect loop optimizations and cause performance regression 
loops have unsafe access. On other hand unsafe accesses have membars so 
it may be not big deal.
At least run Andrew's ByteBuffers ;)

Changes looks fine to me.

Thanks,
Vladimir

On 3/28/17 9:10 AM, Roland Westrelin wrote:
>
> New webrev:
>
> http://cr.openjdk.java.net/~roland/8176506/webrev.02/
>
>> src/share/vm/opto/library_call.cpp:
>>     } else {
>> +    // We know it's an on heap access so base can't be null
>> +    base = must_be_not_null(base, true);
>>       return basic_plus_adr(base, offset);
>>     }
>>
>> Why do you unconditionally apply GK::must_be_not_null() even when base
>> is provably non-null?
>
> It would be optimized out. Anyway, I followed your suggestion and added
> a check.
>
>> Another thing I noticed is that the following check isn't strong enough:
>>
>> 2072 LibraryCallKit::classify_unsafe_addr(Node* &base, Node* &offset) {
>>
>> 2085   } else if (base_type->isa_oopptr()) {
>> 2086     // Base is never null => always a heap address.
>> 2087     if (base_type->ptr() == TypePtr::NotNull) {
>>
>> It doesn't cover TypePtr::Constant case. Fixed it with:
>> -    if (base_type->ptr() == TypePtr::NotNull) {
>> +    if (!TypePtr::NULL_PTR->higher_equal(base_type)) {
>
> Right. I had noticed that change in your webrev but wasn't sure why it
> was necessary. Thanks for the explanation.
>
>> Otherwise, looks good for 10.
>
> Thanks!
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list