RFR(XS) 8027388: JVM crashes with SIGSEGV (0xb) at pc=0x00000001077cbbf6
Igor Veresov
igor.veresov at oracle.com
Mon Dec 23 19:48:52 PST 2013
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/20131223/067495a5/attachment.html
More information about the hotspot-compiler-dev
mailing list