RFR(M): 8141635: Implement new Unsafe intrinsics on POWER

Doerr, Martin martin.doerr at sap.com
Tue May 3 10:16:54 UTC 2016


I have implemented the C2 intrinsics for the new internal Unsafe methods (used by VarHandles) on PPC64.

According to JEP 193, Compare and Swap/Exchange methods need to behave like volatile load + volatile store.
Therefore, I had to make a change to the shared library_call implementation (support_IRIW_for_not_multiple_copy_atomic_cpu was not yet included).
I also assert that GetAndAdd and GetAndSet are only used with seq_cst semantics, because the memory order is not passed to these intrinsics.

C++2011 supports specifying weaker semantics for failed cases of atomic_compare_exchange than for successful ones.
As I understand JEP 193, Java expects the semantics for failed cases to be the same as for successful cases.
That means the memory barrier instruction must be executed even though the store was not executed. So the failed Compare and Swap/Exchange behaves like a volatile load.

I made an exception to that rule for weak versions of Compare and Swap because they are allowed to fail a little more often as necessary.
They do not return the loaded value, but only report whether the Swap was performed or not. The failure cause is not clearly identifiable and I don't see any purpose of executing a memory barrier in case of failure.

Can somebody confirm if this is as required, please?

Here's the webrev:

Please review. I will also need a sponsor from Oracle, please.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160503/e8367fef/attachment.html>

More information about the hotspot-compiler-dev mailing list