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

[Igor Veresov]

Well, we were faking a store of null to a field. I think what was happening is that we did this for each AddP even the ones associated with loads. And if this was the only thing that was happening to the field it added the nullness information to it. And since compare elimination is based on the nullness in the connection graph it was making wrong decisions.

igor

On Dec 26, 2013, at 10:46 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

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