8144856 : fix assert in CompiledStaticCall::set_to_interpreted
Jamsheed C m
jamsheed.c.m at oracle.com
Mon May 9 11:58:44 UTC 2016
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/
> Besides that the change looks good.
> Best regards,
>> -----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
>> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev