RFR: 8186838: Generalize Atomic::inc/dec with templates

[Erik Österlund]

Hi David,

On 2017-09-07 12:53, David Holmes wrote:
> On 7/09/2017 7:34 PM, Erik Österlund wrote:
>> Hi David,
>>
>> On 2017-09-07 04:10, David Holmes wrote:
>>> <trimming>
>>>
>>> On 5/09/2017 10:09 PM, Erik Österlund wrote:
>>>> Okay, great. So far it sounds like as for Atomic::inc/dec, there 
>>>> are no loud voices against the idea of removing the Atomic::inc/dec 
>>>> specializations. So I propose this new webrev that does exactly that.
>>>>
>>>> Full webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8186838/webrev.01/
>>>>
>>>> Incremental over last webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8186838/webrev.00_01/
>>>>
>>>> I hope this looks simpler.
>>>
>>> Yes this is much simpler.
>>
>> Glad to hear it!
>>
>>> I am still totally dismayed by the complexity that was needed to 
>>> retain the inc/dec specializations. To me it just screams that there 
>>> is something fundamentally wrong with what was being done. :(
>>
>> Okay.
>>
>>> I'm also somewhat perplexed. I can't read inline assembly fluently, 
>>> but looking at the existing inc_ptr implementations, eg for x86, I'm 
>>> not seeing code that adds 1*sizeof(*dest). ??
>>
>> Neither can I.
>
> Okay so ... something not right here. :)
>
> It seems to me that the uses of inc_ptr are actually just bumping a 
> counter by 1, where the counter is defined to be the same size as a 
> ptr ie 32-bit on 32-bit and 64-bit on 64-bit.

That seems right to me. The old add/inc/dec_ptr overloads have the same 
semantics they have always had: they all forward the call to add 1/-1 
with a destination of type pointer to intptr_t or char*. That is - 
either it performs normal integer addition (for intptr_t), or pointer 
scaled add (char*) where the element size of the pointer is 1 
(sizeof(char)). In both cases inc_ptr will add by one when going down 
these old non-generalized explicit *_ptr overloads.

Thanks,
/Erik

> Cheers,
> David
>
>> Thanks,
>> /Erik
>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> /Erik
>>