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

John Rose john.r.rose at oracle.com
Fri Jul 22 22:15:34 UTC 2016

On Jul 22, 2016, at 2:51 PM, Hans Boehm <boehm at acm.org> wrote:
> "Word-tearing" was definitely and consistently used that way in the JSR 133
> discussions.  That's where the JLS terminlogy came from. 

The word that is torn is the word *containing* the datum of interest.
Which is why when people quite naturally assume that "the word"
is the the datum itself, the term is unintelligible.

With "struct tearing" it is more clear that the thing being torn is
in fact the datum of interest.  Where "torn" covers all cases of
"exposes non-semantic memory states in variables".

On Jul 22, 2016, at 1:50 PM, Martin Buchholz <martinrb at google.com> wrote:

> Is it reasonable to add syntax for volatile array elements?

It's difficult.  I've been thinking about this for a while for the related
use case of frozen arrays (array-of-final-T).  With frozen arrays you
need a store check even for primitive arrays.  For volatile arrays
you'd need a load check and a store check for all arrays.

Since all array references include a range check, a JVM implementor
would want to find a clever way of piggy-backing the load and
store checks onto the range check, and then having all the checks
float together out of loops.

Really, an array of volatiles is an oxymoron like a herd of cats
or team of individuals.  In normal arrays there is affinity between
neighboring values; with volatiles there is a basic decoupling
between neighbors, since each has its own distinct sequence
of effects.  (I'm speaking of typical uses of arrays; you can use
arrays as low-level storage where neighbors have no logical
connection with each other.  We optimize for the typical case.)

All this assumes we make array-of-volatile-ints be a subtype
of array-of-int-type.  An alternative today is to have array-like
container types which are *not* related to the legacy array type.
Like a private normal array, accessed only by VH-based atomics.

— John

More information about the jmm-dev mailing list