enhancement of cmpxchg and copy_to_survivor for ppc64

[Volker Simonis]

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.

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;

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?

Regards,
Martin and Volker

On Mon, Apr 18, 2016 at 3:41 PM, Andrew Haley <aph at redhat.com> wrote:
> On 04/18/2016 02:01 PM, Carsten Varming wrote:
>> An important question is: Should the shared parts of hotspot move towards
>> weaker memory models? If yes, then everybody should review code assuming
>> the weaker semantics. If no, then there really isn't room for patches like
>> this one :(.
>
> This would surely be useful.  For example, the bitmap marking uses a
> two-way acquire and release barrier at the moment, and I'm fairly sure
> we don't need that.
>
> I don't think this change should be #ifdef PPC64.  That disadvantages
> other targets such as AArch64, to no advantage.  I understand that
> moving this to shared code requires more work, but we should do at
> least some of it in the JDK9 timeframe.
>
> C++11 has a considerably greater variety of atomic memory operators
> than the ones in HotSpot. Over time I believe we should migrate to
> C++11-like operators in our code base. One way to do this would be to
> create new operators which map in a simple way onto the standard ones.
> The we can get rid of much of this inline assembly code.
>
> Andrew.