8144856 : fix assert in CompiledStaticCall::set_to_interpreted

[Vladimir Kozlov]

Jamsheed, your changes looks good.

Thanks,
Vladimir

On 5/9/16 4:58 AM, Jamsheed C m wrote:
> Hi Goetz,
>
> Thank you for looking at this.
>
> On 5/9/2016 2:22 PM, Lindenmaier, Goetz wrote:
>> Hi Jamsheed,
>>
>> Do you want to avoid that data/destination are changed concurrently
>> between the two compares? Or do you just want to save costs of the call?
> This change was done in x86 as part of JDK-8062493
> <https://bugs.openjdk.java.net/browse/JDK-8062493>.  from the comment in
> the change, it says its meant for first case. but, i couldn't find a
> case in current hotspot code where this could happen.
> may be its a precautionary change. ( Chris can help here).
>>
>> To assure the first, you need to make the two local variables volatile.
>> Else the compilers can add reloads after inlining data() and jump_destination().
>> We observed this with the Visual Studio compiler and xlC on aix.
> i have made the two local variables as volatile.
> revised webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.01/
>
> Best Regards,
> Jamsheed
>>
>> Besides that the change looks good.
>>
>> Best regards,
>>   Goetz.
>>
>>
>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
>>> bounces at openjdk.java.net] On Behalf Of Jamsheed C m
>>> Sent: Freitag, 6. Mai 2016 13:21
>>> To: hotspot compiler<hotspot-compiler-dev at openjdk.java.net>
>>> Subject: RFR: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted
>>>
>>>
>>> Hi,
>>>
>>> Request for review for an assert cleanup change.
>>> bug id :https://bugs.openjdk.java.net/browse/JDK-8144856
>>> webrev:http://cr.openjdk.java.net/~jcm/8144856/webrev.00/
>>>
>>> Best Regards,
>>> Jamsheed
>>>
>