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

[Igor Veresov]

Thanks, Chris!

igor

On Dec 26, 2013, at 12:10 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> That seems to be a much better fix than the last one.  Looks good.
> 
> On Dec 25, 2013, at 6:35 PM, Igor Veresov <igor.veresov at oracle.com> 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> 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> 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> 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> 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
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131226/ee93f0dc/attachment-0001.html