Draft JEP on enhanced volatiles

[Andrew Haley]

On 02/11/2014 09:46 PM, Martin Buchholz wrote:
> 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?

Valgrind has a race checker that can be used for this kind of thing, and
it can probably be utilized for Java.  I wouldn't be surprised if we found
some races in HotSpot.

Andrew.