[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS

[Paul Sandoz]

> On 22 Jul 2016, at 04:57, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Jul 20, 2016, at 1:25 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
>>> 
>>> On Tue, Jul 19, 2016 at 1:51 PM, Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>> wrote:
>>>> On 19/07/16 09:39, Paul Sandoz wrote:
>>>> Plain behaves like non-volatile/non-final field access e.g. like
>>>> get/putfield byte codes.
>>> 
>>> We should probably clarify whether we really mean that even word-tearing on longs/doubles is allowed.
> 
> Putting aside the history and esthetics of terms, the big question
> here is whether to remove the exception for 64 bit types in
> 17.7 (Non-atomic Treatment of double and long), and mandate
> that all primitive types are atomic, including non-volatile longs
> and doubles.
> 
> Is it time to do that yet, or is there some 32-bit JVM out there
> that will fall over if it has to do the volatile dance even on
> non-volatile types?
> 
> I'm going to guess that there still *ARE* such JVMs out there,
> but their number is decreasing exponentially over time.
> Eventually we can do this.
> 
> Argument to keep things as they are:  64-bit non-atomicity
> (aka struct tearing) is just a precursor to non-atomicity of 128-bit
> and larger value types.  It's a permanent feature on our landscape,
> so don't fight it.
> 
> VarHandles provide an easy-enough way to select either the
> atomic or the non-atomic accesses for 64-bit things (right?)

Yes, set/get is not guaranteed to be atomic, all other accesses are under the guidelines Doug mentions in his last email.


> and presumably they will do the same for value types.
> 
> I see one possibly urgent argument to move away from
> non-atomicity of longs in the VH API:  VH's support atomic
> operations on arbitrary, unprepared longs.  (Before, the
> JVM got fair warning of atomicity, because the long
> was tagged as "volatile".  Now any long is fair game.)
> Doesn't that require even plain references to at least
> look around carefully for a VH, before they just move
> the two halves non-atomically?  After all, for large
> structs, the STM required for atomics is *incompatible*
> with the naive component-wise loads and stores.
> 
> Or, do VH's just refuse to perform atomic operations on
> non-volatile longs, on 32-bit machines?
> 

We have some jcstress tests checking atomicity.

The concern i have implementation-wise is AtomicLong has this:

  /**
   * Records whether the underlying JVM supports lockless
   * compareAndSwap for longs. While the intrinsic compareAndSwapLong
   * method works in either case, some constructions should be
   * handled at Java level to avoid locking user-visible locks.
   */
  static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();

  /**
   * Returns whether underlying JVM supports lockless CompareAndSet
   * for longs. Called only once and cached in VM_SUPPORTS_LONG_CAS.
   */
  private static native boolean VMSupportsCS8();

And that field VM_SUPPORTS_LONG_CAS is used only in AtomicLongFieldUpdater. Relevant VarHandle implementations don’t currently make this distinction. At the moment i don’t fully understand the bit about "locking user-visible locks”. However, this seems separate from atomicity.

Paul.



> One way to avoid these corner cases is just chop off
> the corner, and require all JVMs to treat 64-bit primitives
> as atomic, always.
> 
> — John