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

Andrew Haley aph at redhat.com
Mon Apr 23 10:20:39 UTC 2018

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 memoryorderacquirerelease and specify memoryorderconservative 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

More information about the hotspot-dev mailing list