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

[David Holmes]

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

> /Erik
>
>
> On 12 Sep 2014, at 03:40, David Holmes <david.holmes at oracle.com> wrote:
>
>> Hi Erik,
>>
>> Can we pause and give some more thought to a clean mechanism for allowing a shared implementation if desired with the ability to override if desired. I really do not like to see CPU specific ifdefs being added to shared code. (And I would also not like to see all platforms being forced to reimplement this natively).
>>
>> I'm not saying we will find a simple solution, but it would be nice if we could get a few folk to think about it before proceeding with the ifdefs :)
>>
>>
>> Thanks,
>> David
>>
>>
>> On 12/09/2014 7:48 AM, Erik Österlund wrote:
>>> Hi,
>>>
>>> These changes aim at replacing the awkward old jbyte Atomic::cmpxchg implementation for all the supported x86 platforms. It previously emulated the behaviour of cmpxchgb using a loop of cmpxchgl and some dynamic alignment of the destination address.
>>>
>>> This code is called by remembered sets to manipulate card entries.
>>>
>>> The implementation has now been replaced with a bunch of assembly, appropriate for all platforms. Yes, for windows too.
>>>
>>> Implementations include:
>>> bsd x86/x86_64: inline asm
>>> linux x86/x86_64: inline asm
>>> solaris x86/x86_64: .il files
>>> windows x86_64 without GNU source: stubGenerator and manual code emission and hence including new Assembler::cmpxchgb support
>>> Windows x86 + x86_64 with GNU source: inline asm
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8058255
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8058255/webrev/
>>>
>>> Improvements can be made for other architectures can as well, but this should be a good start.
>>>
>>> /Erik
>>>
>