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

[Kim Barrett]

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.