Draft JEP on enhanced volatiles
aph at redhat.com
Wed Feb 12 09:59:51 UTC 2014
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.
More information about the core-libs-dev