enhancement of cmpxchg and copy_to_survivor for ppc64

[David Holmes]

<expanding cc to include hotspot-dev not just runtime>

On 19/04/2016 2:23 AM, 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.
>
> 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?

I think expanding our Atomic and OrderAccess API's to align with the 
C++11 atomic and memory-ordering APIs is a good thing to do - even if we 
don't actually switch to direct compiler support for a while yet. It may 
be challenging to efficiently implement all of the C++11 semantics 
directly in the meantime.

However this is too late for JDK 9 I think, with FC (for hotspot) on May 
12. Though addressing the immediate concern, without trying to 
generalize to full C++11 semantic support may be feasible - eg add a 
"relaxed cas" for use in one or two particular pieces of code.

Thanks,
David


> 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.