8144856 : fix assert in CompiledStaticCall::set_to_interpreted

[Jamsheed C m]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160509/cc1616e8/attachment.html>