enhancement of cmpxchg and copy_to_survivor for ppc64

[Andrew Haley]

On 04/18/2016 05:23 PM, Volker Simonis wrote:
> We've looked at the proposed changes and we are pretty sure that the
> cmpxchg done during copy_to_survivor_space in the parallel GC doesn't
> require the full fence/acquire semantics. But we also agree that this
> should not be ifdefed PPC64 in shared code.
> 
> Andrews suggestion of using the new C++11 atomic memory operators is
> good, although in practice it may be hard to get all the different
> compilers under the hood.

What do you mean?

> But now that we've even got the corresponding cmpxchg routines with
> various acquire/release semantics in Java-land in the new
> jdk.internal.Unsafe package, it would be a pity if it would not be
> possible to use that functionality within the Hotspot.
> 
> I think one approach to enable an easy transition would be to do the
> proposed enhancements (or something similar) to cmpxchg
> unconditionally in atomic.hpp. For example instead of two extra
> boolean parameters we could use an enum similar to the one in
> library_call.cpp:
> 
> typedef enum { Relaxed, Opaque, Volatile, Acquire, Release } AccessKind;

Note that cmpxchg has two args: memory order succeed, and memory
order fail.

> The default value of this parameter should of course be conservative
> (i.e. Volatile) so we don't change the current behavior. After that
> individual, performance critical callers of these routines can be
> examined if they really require the most conservative setting and
> maybe optimized.
> 
> What do you think?

OK, but I think we should use the standard C++ types from std::memory_order
because HotSpot is a C++ program.  These are:

  typedef enum memory_order
    {
      memory_order_relaxed,
      memory_order_consume,
      memory_order_acquire,
      memory_order_release,
      memory_order_acq_rel,
      memory_order_seq_cst
    } memory_order;

I'm not suggesting they should have exactly these names, but it's a really
good idea to insist they have the same semantics.  So:

   { Relaxed, Consume, Acquire, Release, AquireRelease, SeqCst }

I know that there is a (fairly) serious attempt to define the semantics of
Unsafe memory order so that it's compatible with C++.

I'm not sure if Opaque is useful at this level: as far as I can tell
from the opaque (:-) documentation it's like a C++ volatile read.

I'm sure we're going to need memory_order_consume sooner or later:
HotSpot already assumes consume-like behaviour for memory accesses
which have address dependencies.  It would be nice to make such
accesses explicit.

Andrew.