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

[Erik Österlund]

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.

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.

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.

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?

/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
>>