RFR: 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms

[Erik Österlund]

I don't want to break the ported builds so I made a special variant of the third option where the x86 inline methods also have a #define next to them.
The atomic.inline.hpp file then simply defines an inline Atomic::cmpxchg calling the general solution if there is no #define for an override.

That way it's using variant three, but there is no need to write overrides for every platform port (which are sometimes in other repos) there is to simply run the default member function.
We can add them one by one instead. :)

Hope this seems satisfactory.

Thanks,
Erik

On 17 Sep 2014, at 14:28, David Holmes <david.holmes at oracle.com> wrote:

> On 17/09/2014 9:13 PM, Erik Österlund wrote:
>> I am back! Did you guys have time to do some thinking? I see three different solutions:
>> 
>> 1. Good old class inheritance! Class Atomic is-a Atomic_YourArchHere is-a AtomicAbstract
>> Using the CRTP (Curiously Recurring Template Pattern) for C++, this could be done without a virtual call where we want inlining.
> 
> I would prefer this approach (here and elsewhere) but it is not a short-term option.
> 
>> 2. Similar except with the SFINAE idiom (Substitution Failure Is Not An Error) for C++, to pick the right overload based on statically determined constraints.
>> E.g. define if Atomic::has_general_byte_CAS and based on whether this is defined or not, pick the general or specific overload variant of the CAS member function.
> 
> Not sure what this one is but it sounds like a manual virtual dispatch - which seems not a good solution.
> 
>> 3. Simply make the current CAS a normal function which is called from billions of new inline method definitions that we have to create for every single architecture.
> 
> I think the simple version of 3 is just move cmpxchg(jbtye) out of the shared code and define for each platform - there aren't that many and it is consistent with many of the other variants.
> 
>> What do we prefer here? Does anyone else have a better idea? Also, should I start a new thread or is it okay to post it here?
> 
> Continuing this thread is fine by me.
> 
> I think short-term the simple version of 3 is preferable.
> 
> Thanks,
> David