RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms

[Andrew Haley]

On 1/14/20 3:05 PM, Andrew Haley wrote:
> On 1/14/20 3:00 PM, Andrew Haley wrote:
>> On 8/15/19 4:49 PM, Derek White wrote:
>>> However, setting CPU_MULTI_COPY_ATOMIC for AArch64 would result in changing behavior (removing fence in taskqueue) that should be looked at and tested by the aarch64 folks, so if Andrew Haley agrees, I suggest deferring changing this AArch64 behavior to a separate issue.
>>
>> Well, yes. What i don't understand is what any of this has to do with
>> multi-copy atomicity. The fence is needed for _age.get() on all machines
>> with relaxed memory consitency, AFAICS.
>
> Ah, I found the answer in another thread:
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008853.html

   "No, the problem is not reordering.  The problem is that _bottom,
   which is read after _age, might be older than _age because another
   processor didn't write it back yet.  The fence (sync) makes the
   current thread wait until it has the new _bottom.

   "On Power, a write is not visible to all other threads simultaneously
   (no multipl-copy-atomicity)."

So, my question: on a machine with relaxed memory, do we still need an acquire
fence?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671