8144856 : fix assert in CompiledStaticCall::set_to_interpreted
vladimir.kozlov at oracle.com
Mon May 9 18:28:48 UTC 2016
Jamsheed, your changes looks good.
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,
>> 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
>>> Best Regards,
More information about the hotspot-compiler-dev