RFR(XS): 8038048: assert(null_obj->escape_state() == PointsToNode::NoEscape, etc)

[Vladimir Kozlov]

Thank you, Richard

The fix was pushed yesterday:

http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/054e88be4820

And I will backport it into 8u20 later.

Thanks,
Vladimir

On 4/17/14 3:10 AM, Richard Reingruber wrote:
>      > Thank you very much, Richard
>      > Especially thanks for the test.
>
> Pleasure :)
>
>      > I am just wondering how you found this? I still can't reproduce 8038048
>      > (Coleen does). Did you just get the same failure as 8038048 in your
>      > testing?
>
> A certain feature of the SAP JVM makes use of shared memory which is accessed
> through s.m.Unsafe methods. One of the tests for that feature on one of our
> platforms (IBM System Z) triggered the assertion from 8038048
> deterministically. The inlinining tree was big, but as I was able to reproduce
> and debug the failure I saw that handling a StoreP node from the
> Unsafe.putAddress() intrinsic changed the escape state of null_obj.
>
>      > Okay, I see that the original code
>      > ptn->set_escape_state(PointsToNode::GlobalEscape); sets escape state to
>      > null_obj. And set_escape_state(ptn, PointsToNode::GlobalEscape) does not
>      > do that, which is correct.
>
> Right. I should have added a little comment to the webrev.
>
>      > The fix is good.
>
> Thank you very much for reviewing and fixing the issues of the test case.
>
> Thanks / cheers,
> Richard.
>
> On 04/16/2014 08:53 PM, Vladimir Kozlov wrote:
>> On 4/16/14 11:36 AM, Vladimir Kozlov wrote:
>>> Thank you very much, Richard
>>>
>>> Especially thanks for the test.
>>>
>>> I am just wondering how you found this? I still can't reproduce 8038048
>>>   (Coleen does). Did you just get the same failure as 8038048 in your
>>> testing?
>>>
>>> The fix looks correct. I missed this place and fields were not marked as
>>> escaped as result. But I need to look why null_obj was modified and
>>> cause the assert to fail.
>>
>> Okay, I see that the original code ptn->set_escape_state(PointsToNode::GlobalEscape); sets escape state to null_obj.
>> And set_escape_state(ptn, PointsToNode::GlobalEscape) does not do that, which is correct.
>>
>> The fix is good.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> The test needs -XX:+IgnoreUnrecognizedVMOptions since EA is recognized
>>> only bu Server VM. I fix it myself, no problem.
>>>
>>> After testing and verifying that it fix our runThese problem I will push
>>> it.
>>>
>>> Regards,
>>> Vladimir
>>>
>>> On 4/16/14 2:13 AM, Richard Reingruber wrote:
>>>> Hi,
>>>>
>>>> could you please review the following webrev? It contains a reproduction
>>>> test
>>>> case for bug 8038048 and a fix for the bug, which I would like to
>>>> contribute.
>>>>
>>>> Webrev: http://www.sapjvm.com/rr/webrevs/8038048/webrev.01/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038048
>>>>
>>>> The contribution needs to be sponsored as well.
>>>>
>>>> Thanks, Richard.
>>>>
>>>> _______________________________________________________________
>>>> Richard Reingruber | SAP JVM | Technology Development,  SAP AG
>>>>
>>>> Pflichtangaben/Mandatory Disclosure Statements:
>>>> http://www.sap.com/company/legal/impressum.epx
>>>>
>>>>
>