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