Draft JEP on enhanced volatiles

[Martin Buchholz]

On Mon, Feb 10, 2014 at 3:43 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

>
> On Feb 10 2014, at 04:33 , Doug Lea <dl at cs.oswego.edu> wrote:
>
> > Among the constraints on solution is that several of these
> > methods compile down to no-ops on many common platforms.
>
> This is interpreted as a benefit. However, if the are no-ops only for the
> most common platform (x86) then we are likely to see a rough path for other
> platforms. Incorrect or inconsistent usage of these methods in user code
> will, instead of having no effect, result in unexpected and possibly
> mysterious runtime failures on other platforms.


We already have the problem that programs that succeed on x86 may fail on
other platforms with a weaker memory model.

The JVM has been pretty good about hiding these differences thus far. It
> would be nice to see a "least common denominator" non-no-op mode as part of
> the VM implementation that provided the opportunity to test in the most
> pessimistic conditions.
>


If you wanted to be able enable robust testing, create an adversarial VM
implementation (e.g. via hotspot flag) that did maximal compiler
reordering, e.g. between synchronization points write values to main memory
in reverse order.  But that's a big job that's probably not going to happen?