[jmm-dev] ECOOP, JVMLS

[Doug Lea]

On 07/19/2014 08:18 AM, Aleksey Shipilev wrote:
>  I'd think OoTA/JMM9 section needs expanding a bit :)
>
> [1] http://shipilev.net/blog/2014/jmm-pragmatics/
>

I tried to come up with a short MM-consumer (vs MM developer)
accessible summary of OOTA and related issues.
It's not all that short, in part because I tried to relate to
more familiar problems. But even at that, possibly
misleading/wrong in effect.
I'm sure Aleksey would appreciate improvements.

...


OOTA and related problems

You'd think it would be easy to eliminate the possibility of
"thin-air" reads by stating that, even in crazily racy programs, every
read reads from some write that does not happen after it.  But this
does not alone suffice in the presence of access cycles in a program,
as in: Read A can read from write B a value derived from a read from
A, and so on.

Such circularities might seem impossible or uninteresting.  But
because accesses may be reordered, a program that doesn't have any
surface-level cycles may be equivalent to one that does. Further, a
read that appears to be dependent on some other write in a way that
avoids circularities might be optimized into one without the
dependence (for example "0 * x" is not dependent on x).  Thin-air and
circularity issue turn out to be the tip of the iceberg in efforts to
ensure that guarantees hold uniformly across all reorderings and
optimizations.  Dealing with the latter invites enumeration of all
possible optimizations, nearly guaranteeing that some will be missed
and/or incorrectly declared illegal (as is the case for the current
JSR133 JMM).  Acceptable solutions must also respect the limitations
of processors and compilers making "local" decisions about orderings
and values that don't always make sense when dealing with this
non-local constraint. Investigations have led to discovery of some
related anomalies.

This general form of problem also appears similar to that of static
initialization circularities in Java that are addressed by rules
allowing circular accesses to uninitialized fields to see their
default zero (0/0.0/false/null) values. But this is arranged in part
via (reentrant) locking, but which need not be present for arbitrary
accesses.  (Although it seems completely defensible for any solution
here to also allow/admit default-zero as a not-very-thin-air value.)

Why not just get it over with by adding to the rest of the spec a
no-thin-air disclaimer? This might be tolerable for (some) readers, but
much less so for development and analysis tools that otherwise get
stuck because of non-uniform treatment of potential circularities. The
approach to avoiding this in the current (JSR133) JMM has itself been
an impediment to tool development.