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

[Erik Österlund]

Hi Andrew,

On 2018-04-23 12:20, Andrew Haley wrote:
> 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.

I would also like to have seq_cst available. In the Access API, I need 
MO_SEQ_CST for JMM volatile support. I would like the semantic 
requirements to go straight into Atomic, instead of doing a "if 
(support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence(); 
}" dance in shared code, that may or may not make sense at a given 
platform (among other reasons because it enforces whether leading or 
trailing sync convention is used in shared code, rather than leave that 
decision to the platform level). Plus I have a mouse pad that says I 
love sequential consistency, although that might not be a valid argument 
to introduce this to Atomic.

Thanks,
/Erik