[jmm-dev] RFR 8154755: Add a VarHandle weakCompareAndSet with volatile semantics

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Apr 29 12:36:29 UTC 2016


Looks good.

Best regards,
Vladimir Ivanov

On 4/21/16 7:21 PM, Paul Sandoz wrote:
> Hi,
>
> Please review:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154755-weak-cas-volatile/webrev/
>
> This webrev adds a new VarHandle access mode method, weakCompareAndSetVolatile [*]. (I also fixed some doc errors regarding AccessMode enum names that i forgot to update in a previous issue).
>
> Aleksey noticed a discrepancy with the current set of weak CAS methods when comparing with C++ atomics.
>
> On hardware that supports LL/SC (e.g. ARM) the weak volatile variant may be more performant than the strong volatile variant (compareAndSet) when the CAS is performed in a loop.
>
> See the thread on the jmm-dev list for more details:
>
>    http://mail.openjdk.java.net/pipermail/jmm-dev/2016-April/000239.html
>
>
> Implementations currently defer to the strong volatile Unsafe CAS. We will follow up with changes to Unsafe, hotspot, and updating the VH implementations as separate issues.
>
> Thanks,
> Paul.
>
> [*]
> /**
>   * Possibly atomically sets the value of a variable to the {@code newValue}
>   * with the memory semantics of {@link #setVolatile} if the variable's
>   * current value, referred to as the <em>witness value</em>, {@code ==} the
>   * {@code expectedValue}, as accessed with the memory semantics of
>   * {@link #getVolatile}.
>   *
>   * <p>This operation may fail spuriously (typically, due to memory
>   * contention) even if the witness value does match the expected value.
>   *
> ...
>   */
> public final native
> @MethodHandle.PolymorphicSignature
> @HotSpotIntrinsicCandidate
> boolean weakCompareAndSetVolatile(Object... args);
>
>
>
>
>
> Paul.
>


More information about the jmm-dev mailing list