RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

Kim Barrett kim.barrett at oracle.com
Mon May 21 03:59:47 UTC 2018


> On May 18, 2018, at 5:12 PM, Michihiro Horie <HORIE at jp.ibm.com> wrote:
> 
> Dear all,
> 
> I update the webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.09/
> 
> With the release barrier before the CAS, new_obj can be observed from other threads. If the CAS succeeds, the current thread can use new_obj without barriers. If the CAS fails, "o->forwardee()" is ordered with respect to CAS by accessing the same memory location "_mark", so no barriers needed. The order of (1) access to the forwardee and (2) access to forwardee's fields is preserved due to Release-Consume ordering on supported platforms. (The ordering between "new_obj = o->forwardee();" and logging or other usages is not changed.)
> 
> Regarding the maintainability, the requirement is CAS(memory_order_release) as Release-Consume to be consistent with C++11. This requirement is necessary when a weaker platform like DEC Alpha is to be supported. On currently supported platforms, code change can be safe if the code meats this requirement (and the order of (1) access to the forwardee and (2) access to forwardee's fields is the natural way of coding).

Relying on implicit consume has been been discussed and rejected, in
the earlier thread on this topic and I think elsewhere too.

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021538.html



More information about the hotspot-gc-dev mailing list