RFR(XS) 8027388: JVM crashes with SIGSEGV (0xb) at pc=0x00000001077cbbf6

[Vladimir Kozlov]

I agree that new fix should also work for this case.

How previous fix breaks pointers compare?

Thanks,
Vladimir

On 12/25/13 6:35 PM, Igor Veresov wrote:
> Here’s another, probably, easier approach - in
> adjust_scalar_replaceable_state() we iterate over the uses of an object,
> and if it has a field that has multiple bases, and null is one of them,
> it is made non-scalarizable.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8027388/webrev.01/
> Testing: jtreg, ctw, jprt
>
> Thanks!
> igor
>
> On Dec 24, 2013, at 11:35 AM, Igor Veresov <igor.veresov at oracle.com
> <mailto:igor.veresov at oracle.com>> wrote:
>
>> The fake null store doesn’t quite work and breaks the pointer compare
>> optimization in escape analysis. I have to go back and think of a
>> better solution.
>>
>> igor
>>
>> On Dec 23, 2013, at 7:48 PM, Igor Veresov <igor.veresov at oracle.com
>> <mailto:igor.veresov at oracle.com>> wrote:
>>
>>> I’ll fix that. Thanks for the review, Chris!
>>>
>>> igor
>>>
>>> On Dec 23, 2013, at 7:22 PM, Christian Thalinger
>>> <christian.thalinger at oracle.com
>>> <mailto:christian.thalinger at oracle.com>> wrote:
>>>
>>>> *+         // assume that the result of the LoadP is the the argument of the StoreP.*
>>>> Typo: “the the”
>>>>
>>>> The fix is good.
>>>>
>>>> On Dec 21, 2013, at 12:53 AM, Igor Veresov <igor.veresov at oracle.com
>>>> <mailto:igor.veresov at oracle.com>> wrote:
>>>>
>>>>> Given the following graph, escape analysis currently fails to track
>>>>> the fact that we can load from null.
>>>>>
>>>>>  Allocate A <-- ...---------- StoreP
>>>>>  Allocate B <-- ... - AddP <--/
>>>>>           \
>>>>>            Phi <--- ... -- AddP <--- LoadP
>>>>>  null <-- /
>>>>>
>>>>> The AddPs may refer to the same field of B, however, B could be
>>>>> null so we cannot assume that the result of the LoadP is the the
>>>>> argument of the StoreP.
>>>>> We don't want to add edges to null_obj for performance reasons, so
>>>>> we handle this case by faking the effect of storing a null to this
>>>>> field, which will force a potential non-escaping object (that is
>>>>> also stored to this field) to be marked as not scalarizable. The
>>>>> end result is the same -- we cannot predict that value of the
>>>>> field. Notice that if B is non-escaping it will be made
>>>>> non-scalarizable as well because the field has two bases.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8027388/webrev.00/
>>>>> Testing: jtreg, ctw
>>>>>
>>>>> Huge thanks to Vladimir for discussions and helping me out with
>>>>> this problem!
>>>>>
>>>>> igor
>>>>
>>>
>>
>