RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
aph at redhat.com
Tue Oct 11 09:25:52 UTC 2016
On 06/10/16 23:16, Kim Barrett wrote:
> The key issue here is that we copy obj into new_obj, and then make
> new_obj accessible to other threads via the CAS. Those other
> threads might attempt to access data in new_obj. This suggests the
> CAS ought to have at least a release fence to ensure the copy is
> complete before the CAS is performed. No amount of fencing on the
> read side (such as in the work stealing) can remove that need.
> And that might be all that is needed. On the post-CAS side, we load
> the forwardee and then load values from it. I thik we can use
> implicit consume with dependent loads (except on Alpha) plus the
> suggested release fence to get the desired effect.
That's probably true, except that there's not really any such thing as
"implicit consume" in C++. While all of the hardware we use respects
address dependencies, it's not something that the compiler knows
about, and it's explicitly undefined behaviour in the C++ memory
model. If we're depending on memory_order_consume, perhaps we ought
to think about adding it to Atomic, even though it's just a volatile
load in older compilers.
More information about the hotspot-runtime-dev