RFR: 8067790: Better support for native implementations of Atomic::cmpxchg
kim.barrett at oracle.com
Tue Jan 6 20:27:23 UTC 2015
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
> 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
>> 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
> 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.
More information about the hotspot-dev