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

Erik Österlund erik.osterlund at oracle.com
Tue Sep 5 12:09:18 UTC 2017


Hi Kim,

On 2017-09-05 12:31, Kim Barrett wrote:
>> On Sep 5, 2017, at 10:55 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>> On 2017-09-05 02:38, Kim Barrett wrote:
>>> […] Erik's proposal also uses IntegralContant for that purpose,
>>> but (from a quick skim) I think got that part wrong, and that is a
>>> source of additional complexity. Erik might want to re-read my handoff
>>> email to him.  I don't know whether that approach would satisfy folks
>>> though.
>> Unfortunately that approach did not work. It passed IntegralConstant as rvalue to operator(), which is illegal as IntegralConstant is an AllStatic class.
> IntegralConstant is an AllStatic?  That’s just wrong!  And probably my fault too.

It is indeed.

> // A type n is a model of Integral Constant if it meets the following
> // requirements:
> //
> […]
> // n::value_type const c = n() : c == n::value

Fair point. That should probably be fixed if somebody wants to pass 
around IntegralConstant by value in some later RFE.

>
>>> I'm a little bit reluctant to just give up on per-platform
>>> microoptimized inc/dec and simply transform those operations into
>>> corresponding add operations.  Requiring an additional register and
>>> it's initialization for some platforms seems like poor form.
>> If we insist on having these micro optimizations, I am not opposed to on selected x86 GCC platforms (were the risk for future ABI breakage is nearly zero) using GCC intrinsics for Atomic::add. If Atomic::inc/dec simply calls Atomic::add, then those GCC intrinsics will be able to micro optimize as you desire to the optimal lock add encoding.
> I think I’d be okay with that too.

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.

Thanks,
/Erik


More information about the hotspot-dev mailing list