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

[Doerr, Martin]

Hi David,

thank you very much for sponsoring and your support.
The main bug JDK-8154736 is currently targeted to 10. I guess we will have to discuss it on the gc mailing list and request it for 9.

Best regards,
Martin

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Mittwoch, 22. Juni 2016 05:16
To: Kim Barrett <kim.barrett at oracle.com>; Doerr, Martin <martin.doerr at sap.com>
Cc: Tim Ellison <Tim_Ellison at uk.ibm.com>; ppc-aix-port-dev at openjdk.java.net; Hiroshi H Horii <HORII at jp.ibm.com>; hotspot-runtime-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg

Finally pushed:

Changeset: 1daa31adf6fc
Author:    mdoerr
Date:      2016-06-21 19:25 -0400
URL:       http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1daa31adf6fc

8155949: Support relaxed semantics in cmpxchg
Reviewed-by: dholmes, kbarrett, goetz, aph
Contributed-by: horii at jp.ibm.com, martin.doerr at sap.com

Thanks,
David
------

On 26/05/2016 11:29 AM, David Holmes wrote:
> Filed: https://bugs.openjdk.java.net/browse/JDK-8157904
>
> Atomic::cmpxchg_general for jbyte is missing a fence on initial failure
>
> David
>
> On 26/05/2016 11:09 AM, David Holmes wrote:
>> Hi Kim,
>>
>> On 26/05/2016 10:04 AM, Kim Barrett wrote:
>>>> On May 24, 2016, at 5:37 AM, Doerr, Martin <martin.doerr at sap.com>
>>>> 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.
>>>>
>>>> Webrev is here:
>>>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.05/
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>  100 inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte
>>> *dest, jbyte comparand, cmpxchg_memory_order order)
>>>
>>> The addition of the order option makes it a bit more obvious that this
>>> does not, and never has, executed any fences in the immediate failure
>>> case, e.g. when
>>>
>>>  111   while (cur_as_bytes[offset] == comparand) {
>>>
>>> is false on the first iteration.  This seems like a bug.  Assuming it
>>> is, I'm not sure whether this should be dealt with as part of this
>>> changeset, or moved to a separate bug for this (pre-existing) issue.
>>> I think only ARM targets (and zero?) are lacking specialized cmpxchg
>>> on bytes and so use this version?
>>
>> I'll file a separate bug for that.
>>
>> Thanks,
>> David
>> ------
>>
>>
>>> Sorry I didn't notice this previously.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>>> Other than that and the already mentioned (pre-existing) Atomic::add
>>> for jlong return value problem, this looks good.
>>>