RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms
martin.doerr at sap.com
Tue Aug 13 10:30:20 UTC 2019
Hi Kim and David,
thank you for looking into this issue.
I've replied to your comment in the issue.
> I find the inversion of the ifdef slightly confusing. I also don't like
> a comment to say we don't have a given property. Wouldn't it be better
> to set CPU_MULTI_COPY_ATOMIC to 0 or 1 as appropriate?
Hmm. We could change that. I'm not sure what is better.
I think it should be designed such that correct usage is easy and wrong usage is difficult.
It has already happened that people used an #ifdef for a macro which is always defined (0 or 1) by mistake.
That's why I'm not a big fan of defining things to 0 or 1.
With the #define or not define approach, all platforms except those which explicitly specify the property are conservatively treated as non-multi-copy atomic.
But if your version is preferred by all reviewers, I can use it.
> Can't comment on ppc64 specifics.
I'll ask for additional reviews once the main issue was reviewed.
> It's not at all obvious to me that the need for the fence() in
> pop_global is directly related to CPU_MULTI_COPY_ATOMIC. I prefer to see
> that define connected only with the IRIW issue as it currently is.
This was explained in the email thread a few emails later:
More information about the hotspot-gc-dev