RFR(M): 8155949: Support relaxed semantics in cmpxchg

[David Holmes]

On 24/05/2016 7:37 PM, Doerr, Martin wrote:
> Hi David and Andrew,
>
> sorry for missing this one. There were too many emails.
>
> After moving the jint version as well, there was not much left of atomic.cpp.
> I think it doesn't make any sense to keep a couple of trivial functions in the cpp file.
> Therefore, I have removed atomic.cpp and moved the remaining small functions into the inline file.

Sorry I don't understand why the jbyte cmpxchg_general was moved to the 
.inline.hpp file - it seems far too big to be inlined.

David

> Webrev is here:
> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.05/
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 24. Mai 2016 05:50
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: Hiroshi H Horii <HORII at jp.ibm.com>; Tim Ellison <Tim_Ellison at uk.ibm.com>; ppc-aix-port-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg
>
> Hi Martin,
>
> On 23/05/2016 7:29 PM, Doerr, Martin wrote:
>> Hi David,
>>
>> here's the new webrev:
>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.04/
>
> There seems to be some confusion. You've moved the jbyte
> Atomic::cmpxchg_general from the .cpp file to the .inline/hpp file, but
> the comments from Andrew and Kim were about moving the unsigned
> Atomic::cmpxchg version. ??
>
> Aside: In the changeset contributor's have to be specified by "email
> address" or "name <email address>", OpenJDK user names are not accepted.
> I think Andrew should also be listed there for the Aarch64 component.
>
> Thanks,
> David
>
>> Btw.: The jbyte version of cmpxchg can be implemented on aarch like on ppc where we emulate the byte access by a 4 byte access (lwarx/stwcx). But that should better be done in a separate change.
>>
>> Thanks for your time and your support.
>>
>> Best regards,
>> Martin
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Samstag, 21. Mai 2016 01:10
>> To: Doerr, Martin <martin.doerr at sap.com>
>> Cc: Hiroshi H Horii <HORII at jp.ibm.com>; Tim Ellison <Tim_Ellison at uk.ibm.com>; ppc-aix-port-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg
>>
>> Hi Martin,
>>
>> Are you in a position to make the change now suggested by both Kim and
>> Andrew? Can you also include the Aarch64 code that Andrew provided:
>>
>> http://cr.openjdk.java.net/~aph/8154736
>>
>> I'd like to get this finalized so it is ready to push as soon as the
>> process allows it to.
>>
>> Thanks,
>> David
>>
>> On 20/05/2016 8:03 AM, Kim Barrett wrote:
>>>> On May 18, 2016, at 6:12 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
>>>>
>>>> Hi Kim,
>>>>
>>>> thank you very much for the detailed review.
>>>>
>>>> I agree with your comments and I have made all your requested changes here:
>>>> http://cr.openjdk.java.net/~goetz/wr16/8155949-relaxed_cas/webrev.03/
>>>>
>>>> It's correct that the change changes the semantics of the conservative cmpxchg. In case of failure, we also execute the sync instruction, now.
>>>> Advantage is that the new implementation is maximum conservative by default. I think this makes sense as long as the semantics of the hotspot C++ cmpxchg are not clearly specified.
>>>>
>>>> For performance optimization, we should better use (or introduce additional) enum values.
>>>
>>> ------------------------------------------------------------------------------
>>> There doesn't seem to have been any change for this earlier comment.
>>>
>>> src/share/vm/runtime/atomic.cpp
>>> 59 unsigned Atomic::cmpxchg(unsigned int exchange_value,
>>>  60                            volatile unsigned int* dest, unsigned int compare_value,
>>>  61                            cmpxchg_memory_order order) {
>>>
>>> I'm surprised this was ever out-of-line. But with this change it's
>>> quite bad to be out-of-line, as that's going to kill the constant
>>> propogation of the order value.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Other than that, looks good.
>>>
>>>
>>>
>>>