RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)

[Andrew Haley]

On 04/18/2018 05:37 PM, Doerr, Martin wrote:

> It'd be great if we could specify semantics for Atomic:add like we
> do for Atomic::cmpchgx.
> However, the double-fence is a very bad default from performance
> perspective. I wonder if PPC64 is the only platform which gets hit.

Probably not.

> Would it be acceptable to set the default to
> memory_order_acquire_release and specify memory_order_conservative
> for the new usage? I think this would fit perfectly for PPC64, but
> some people may not like it. One could say PPC64 is the problem, but
> one could also say the VM code is the problem ��

Indeed.  In as much as we use stronger memory ordering than we need in
more than one place, the VM code is the problem.

> I don't really like the straight forward fix to insert a fence with
> #ifdef AIX.

I agree.  It looks to me like it's sufficient if the increment of
global_counter and the load of thread->get_rcu_counter() are
sequentially consistent.  On at least one platform, AArch64, we can
do that without additional fencing.

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