RFR: 8067790: Better support for native implementations of Atomic::cmpxchg

[Erik Österlund]

Hi Kim,

Thank you for your comments. At least now there is only one point we disagree about: the inheritance check. I agree it would be nicer if a compiler error was generated if the derived class was not of expected type rather than reverting to the fallback class automatically. That could trivially be fixed with your permission. (they are already split now anyway - first it checks for existence then for inheritance, and generating an error then is trivial)

I also agree that this could indeed be done without the inheritance check, but I still think it is better to perform that inheritance check as I think having a stronger contract is better for reasons already stated. So if you let me I could turn the inheritance check into a check that generates an error if an unexpected class is used rather than selecting the fallback class.

However, if you really don't want the inheritance check and require a looser contract, I'm willing to give it up and come to your side so we get somewhere even though I disagree about it.

Thanks,
/Erik

> On 6 jan 2015, at 21:27, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> On Jan 6, 2015, at 5:37 AM, Erik Österlund <erik.osterlund at lnu.se> wrote:
>> 
>> On 6 jan 2015, at 00:03, Kim Barrett <kim.barrett at oracle.com> wrote:
>> It is true that in our case nothing would break if the 3 Atomic classes were not explicitly related by inheritance, but implicitly related with duck typing. 
>> 
>> However I want to give the user of SelectBaseClass a stronger contract that the base class can be used reliably and must behave consistently because I think that's better than loose implicit promises.
> 
> Strengthening the selection requirements is a mistake for this general
> technique. When the optionally defined platform-specific class is
> defined, we want to (attempt to) use it.  If there are additional
> requirements on the class that it fails to meet, that should result in
> a compilation error, not a selection failure that results in fallback
> to the generic class.
> 
>> I was never a big fan of duck typing.
> 
> Sorry, you lost me there; duck typing is fundamental to template
> usage.
> 
>> The metafunctions have pretty good synergies. And just to make it clear, I know for a fact I will need IsBaseOf (and some of the other metafunctions) anyway to implement automatic closure specialization (e.g. to distinguish between ExtendedOopClosure and OopClosure). So if we do not introduce them now I will still have to introduce them later on.
> 
> Perhaps IsBaseOf will be needed for that other feature.  [I've not
> looked at it recently or with sufficient care to have a well informed
> opinion on that right now, though I'm a little suspicious; that sounds
> like using class inheritance as a stand-in for a concept check.]  If
> IsBaseOf is needed for that (or for some other) feature, then it can
> be added in conjunction with, or as a prelude to, that feature.
> 
> I claim that the Atomic cmpxchg support doesn't need (and should not
> use) IsBaseOf and the associated infrastructure, and so that
> infrastructure shouldn't be piggy-backing into the code base under the
> cover of the Atomic cmpxchg changes.
> 
>>> In those cases where an inheritance relationship really *is* needed, I
>>> think the right approach is to use conditional existence for selection
>>> and then static assert the needed base/derived relationship(s). For
>>> that we would need an IsBaseAndDerived or IsBaseOf, but their use
>>> would be appropriately conditionalized on the existence of the
>>> optional class (possibly only implicitly, e.g. if Atomic needed to be
>>> derived from AtomicBase then we would assert that, and not care
>>> whether it was direct derivation or via AtomicPlatform).
>> 
>> I do not think it is better to leave correctness detection that could be done automatically to be done manually by the programmer for every use of the function.
>> 
>> This seems to me equivalent to saying it is better to use duck typing and write unit tests to detect type errors to be less constrained by a type system. Some may argue this is true but I like my automatic type checks and stronger contracts. But then again such arguing could go on forever without reaching a conclusion. :)
> 
> The inheritance-based selection criteria does not automatically check
> for correctness.  Instead, it masks errors by falling back to the
> generic behavior.
> 
>>> I strongly care about semantics and risk of error for something that
>>> is billed as a general purpose utility. Risk of ODR violations is not
>>> something I would treat lightly. And minor maintainance changes could
>>> easily lead to such, if this proposed IsBaseOf were used as a general
>>> utility.
>> 
>> Point taken, and IsBaseOf is fixed now as you wanted it.
> 
> Good.  That's what we'll want, when we want IsBaseOf.
> 
>> I will provide automatic closure specialization using this template infrastructure (given somebody is willing to run jprt for me hehe).
> 
> I need to get back to that stuff.  Stefan Karlsson and I recently
> talked about some ideas in that area too.  There certainly seems like
> there should be room for improvement; I may not think macros are
> inherently ugly, but I would be hard pressed to argue for the beauty
> of the present oop iterator stuff.
> 
>> I hope we are converging a bit now with opinions.  […] I think that leaves us to a final issue: Stronger contract enforcing inheritance in SelectBaseClass or weaker relying on duck typing […]
> 
> I'm not sure we are converging; we disagree on the selection criteria,
> and that's quite fundamental.  Waiting to see if my arguments above
> convince you to come around to my position.
> 
>