[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