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

[John Rose]

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?)
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?

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