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

Richard Reingruber richard.reingruber at sap.com
Thu Apr 17 10:10:32 UTC 2014


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



More information about the hotspot-compiler-dev mailing list