RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering.

[Lindenmaier, Goetz]

Hi David, 

As for all changes in the PPC port, I don't intend to change 
anything on your platforms.
To our understanding, the low level operations fulfill the requirements.
Also, we are using this now for around 6 years on ia64 and ppc.
It performs measurable better, and did not raise problems.

Matching the nodes together is hard, because matching
operations having memory inputs isn't supported, as I understand.
I assume this would require changes to the matcher that are more
likely to affect other platforms than adding a field to nodes.

But as you mention in 7143664, we also find it hard to generate
optimal code with the given orderAccess implementations. (Both 
in the compiler and the runtime code.)
To me, it seems to be very hard to find a common, optimal scheme
as the instructions offered on the different processors have 
different semantics.

E.g., MemBarAcquire in the compiler is used after Loads, after 
Cmpxchg, and for Unsafe.acquire.  On some platforms, cmpxchg
orders memory, on others not, so we need to issue different 
member instructions after cmpxchg and loads.  This is not 
reflected in the IR.  But this is not scope of this change.

Best regards,
  Goetz. 

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Montag, 14. Oktober 2013 04:20
To: Lindenmaier, Goetz
Cc: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov
Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering.

Hi Goetz,

As I wrote in the bug report:

"This needs to be considered very carefully. The only time C2 needs to 
be concerned with memory ordering is for Java volatiles and in that case 
there are both atomicity and ordering issues to consider. In addition we 
have to ensure that the low level load.acq and st.rel instructions 
provide the correct semantics to implement volatile variables.

Rather than change the kind of nodes I would have expected that the 
actual code generation would combine the load+membarAcquire nodes into 
the relevant ld.acq instruction if applicable!

Also see JDK-7143664."

This is up to the compiler guys of course.

Cheers,
David


On 11/10/2013 11:34 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I prepared a webrev for 8024921<https://bugs.openjdk.java.net/browse/JDK-8024921>Extend Load and Store nodes to know about memory ordering.
> This is part of the PPC port.
> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/
>
> For a detailed description see the text in the webrev and bug description.
>
> All this basically does is add a field to load and store nodes and
> change all constructor calls to set this field.  So the effect on
> existing platforms should be very small.  Therefore I marked this
> 'M', although quite some lines of code are touched.
>
> Please review and test this change.
> I'm happy to incorporate your comments and any improvements
> you propose.
>
> Best regards,
>    Goetz.
>
>
>
>