RFR: 8186476: Generalize Atomic::add with templates

[Erik Osterlund]

Hi Andrew,

> On 22 Aug 2017, at 16:56, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 22/08/17 15:02, Erik Österlund wrote:
>> Hi Andrew,
>> 
>>> On 2017-08-22 11:06, Andrew Haley wrote:
>>>> On 21/08/17 14:10, Erik Österlund wrote:
>>>> When it comes to the proposed Atomic::add implementation, it seems to me
>>>> like the emulation of Atomic::add on jshort using jint is very similar
>>>> to how Atomic::cmpxchg on jbyte is emulated using jint. So it surprised
>>>> me a bit that Atomic::add of jshort does not share the same mechanism as
>>>> the generalized Atomic::cmpxchg of jbyte.
>>> Indeed.  It also seems rather weird to jump through these hoops on
>>> targets which do have support for adds on jshort.  Still, as you say
>>> it's only used in once place and I guess it doesn't hurt.  I don't
>>> like the undefined behaviour there, though.  It would be nice if there
>>> were none on targets with proper support.
>>> 
>> 
>> Is that a request or are you happy enough with the proposed solution?
>> In case it was really meant as a request, how about something like this?
>> 
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8186476/webrev.01/
>> 
>> Full:
>> http://cr.openjdk.java.net/~eosterlund/8186476/webrev.02/
> 
> Nope, that cure is worse than the disease, but thank you lots for trying.
> :-)

You are welcome. The pleasure is mine!

> I'd fix it at the source by merging those two fields and unpacking as
> required, but I guess there'd be some pushback.

Then for now I am happy with keeping it the way Kim proposed for now, if you are okay with that.

Thanks,
/Erik

> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671