[jmm-dev] ECOOP, JVMLS

[Peter Sewell]

On 19 July 2014 17:27, Doug Lea <dl at cs.oswego.edu> wrote:
> 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.

The best description we've come up with of OOTA issues is Section 4 of
the draft I sent around:
http://www.cl.cam.ac.uk/~pes20/cpp/c_concurrency_challenges.pdf



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

the above sentence may be misleading - if we knew how to *state* such
a disclaimer (in a way compatible with enough optimisation and h/w
behaviour), we'd be done already.

best,
Peter


> 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.
>
>
>
>